Key Function

To mount a volume, just access the container or device file of a disk partition in the main dialog by clicking Select File or Select Device. In the list box in the upper half of the window, you then select a volume under Slot. On Linux, you define a slot number (<n>) in the mountpoint /media/veracrypt<n>, and on Windows, a drive letter. If you want to mount the object in a different directory, click Options in the Mount dialog, and in Mount at directory, enter the target path.

Then specify the password or keyfile. Whether you mount the outer container or – if available – the inner container, is decided exclusively by the password and keyfile. As explained in the "Plausible Deniability" box, you will always use the inner volume in daily operation, but if you mount an outer container with an embedded inner container, in Options you need to check the Protect hidden volume when mounting outer volume box and enter the password for the inner container, too (Figure 7).

Figure 7: You need to know the passwords of both the outer and the hidden containers to enable the protected mode that prevents the inner container from being overwritten.

Clicking Dismount unmounts the device, and VeraCrypt explicitly clears the password from memory. Besides this, VeraCrypt offers a Dismount All button, which closes all open containers as soon as possible. Because the software needs the password constantly during operation, you cannot prevent it remaining in memory while containers are active. This also applies to both of the Linux on-board solutions.

If the system crashes with open containers, you face a residual risk: In case of memory shortage, the operating system writes sections of the main memory to a swap file on the hard disk. Under certain circumstances, the password for active VeraCrypt volumes could thus survive a system power off – if you suspend to disk, this happens in any case. However, this usually only proves to be risky if it falls into the hands of a forensics professional with appropriate knowledge of the system.

You can avoid this risk with full system encryption (e.g., as set up by the Linux installer on Ubuntu) because this also encrypts the swap partition.

Systematically Hidden

On Windows, VeraCrypt's capabilities go much further: In the hidden inner container on Windows you can install a second hidden operating system whose existence is not demonstrable (Figure 8). The special bootloader used for this does not work with Linux, and a posting from the VeraCrypt forum suggests that this situation is not likely to change any time in the near future [13].

Figure 8: On Windows, VeraCrypt supports encrypting a complete operating system in a hidden partition. The Linux version does not have such a function.

Of course, the free operating systems offer many well-known solutions: cryptsetup, a tool that offers full system encryption and comes with many Linux installers, has been able to unlock VeraCrypt volumes since version 1.6.7 from spring 2015. However, both Ubuntu 15.10 and openSUSE 42.1 still use older versions; only Arch Linux already uses the current Cryptsetup release. It relies on a shell script to unlock the root filesystem embedded in the initial ramdisk, which is a file archive the kernel mounts provisionally as root at bootup. This archive contains kernel modules for the filesystems and a shell. Scripts create the conditions for mounting the final root filesystem.

To cooperate with VeraCrypt volumes, you need to extend the standard version of this script; for users with shell skills, this is not too difficult. The initial ramdisks of other distributions [14] work in a similar way to those for Arch, which is why the process can be transferred in principle to this script [15].

Listing 1 shows a section of the /usr/lib/initcpio/encrypt shell script, which asks for the password that will unlock the root filesystem. Line 5 shows the call to dm-crypt via cryptsetup with the parameter --type luks, which is the most common encryption format for Linux partitions.

To use VeraCrypt instead of LUKS, you just need to replace the parameter --type luks with --type tcrypt --veracrypt for a TrueCrypt container with the VeraCrypt sub-format. To ensure that encryption with LUKS still works, all you need is a simple if clause to check for the existence of the vera=1 boot parameter and store the container type in a variable (Listing 2).

In the Cryptsetup call, simply replace --type luks with the ${type} variable. Dm-crypt does not automatically search for a hidden container; instead, you need to stipulate the additional --tcrypt-hidden option. The script thus handles the task of checking for both versions. In the tuned version, it tries the first password entered for the outer container. If it fails to unlock the container, it again prompts for a password, but now tries this on the inner container, then again on the outer container, and so on.

This process is not particularly convenient, especially because it takes time for VeraCrypt to reject an incorrect password. However, at least this process does not reveal any evidence of the hidden container. You need to replace the code in Listing 1 with the code shown in Listing 3 for this. You can download the complete vencrypt script file for Arch Linux online [16].

Now the question arises as to how to install Arch Linux instead of Windows in a hidden VeraCrypt partition. The easiest way is by preparing an Arch Linux machine with the VeraCrypt GUI in a partition on a second hard drive and mounting the hidden container. It must be at least the same size as the current system. You need to consider whether you want to set up an alibi system in the outer container when defining the size of the container.

Installing on a second disk is safer because you do not need to touch the bootloader of the old system. You decide in the BIOS/EFI which system boots. An Rsync call [17] transfers the current system to the mounted VeraCrypt partition – in the example in Listing 4, to /mnt/veracrypt1.

In addition to the root partition, an encrypted system needs an unencrypted boot partition, for which you need to create another 100MB partition. Format it with:

mkfs.ext4 /dev/sd<xN>

You replace <xN> with the identifier for the matching device file and copy to it the contents of the /boot directory from the current system.

Startup Aid

What now follows are some steps already familiar to Arch Linux users from the initial installation of their system. On the mirrored system, first change the fifth line in <Mountpoint>/etc/default/grub to:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/sd<xN>:veracrypt1 vera=1"

The cryptdevice keyword points to the partition encrypted with VeraCrypt. The colon is followed by the name of the mapper in /dev/mapper/ (e.g., veracrypt1 here), which VeraCrypt uses to access the currently mounted partition.

Copy the modified vencrypt script available online [16] to the <Mountpoint>/usr/lib/initcpio/hooks/ directory. To be able to install in the initial ramdisk, you need to duplicate <Mountpoint>/usr/lib/initcpio/install/encrpyt as vencrypt.

Now register the modified vencrypt script under <Mountpoint>/etc/mkinitcpio.conf; optionally, replace the existing original Arch Linux encrpyt version. The HOOKS line responsible for this [18] might then read as follows:

HOOKS="base udev autodetect modconf block filesystems keyboard keymap vencrypt fsck"

The order is important: vencrypt needs to follow filesystems and keyboard but must occur before fsck. The keymap lets you change the keyboard mapping if needed; otherwise, leave any existing hooks in your system unchanged.

Now it is time to use chroot (change root) to change to the new system. The arch-chroot script from the Arch Linux installation medium [19] handles this task; you can call it with ./arch-chroot <Mountpoint>. The Ubuntu guide for fixing GRUB [20] also starts a chroot environment. Now you should change /etc/fstab as shown in Listing 5.

Now mount /boot and install GRUB on the new disk. On BIOS systems, use the grub-install /dev/sd<X> command; for EFI systems, check out the Arch wiki [21]. Next, generate a grub configuration with the parameters inserted into /etc/default/grub with:

$ grub-mkconfig -o /boot/grub/grub.cfg

The only thing missing is the initial ramdisk, which you can created with mkinitcpio -p linux. Now the encrypted system should boot from the second hard drive. Acknowledge the first password prompt after the GRUB menu by pressing Enter; the password is for the outer volume and will fail accordingly. After entering the password for the hidden volume at the second prompt, the system derived from the unencrypted original system boots (Figure 9).

Figure 9: You've done it! Arch Linux is running in a hidden VeraCrypt container mounted under /dev/mapper/veracrypt1.

For maximum deniability, use Rsync to mirror a Linux system in the outer container as well, and give it the same /etc/fstab file. The entry in the bootloader is fine for both systems and therefore does not require any further modification.