Current Linux distributions make it easy to use encryption to secure your home directory against prying eyes. But encrypting whole partitions also has some drawbacks: First, you need to decide whether to encrypt whole partitions when installing the system. Second, encryption makes data recovery more difficult if you cannot boot the system.

Swapping an encrypted partition out to another disk is also tricky. Many users thus prefer to use encrypted containers like the ones that you can (or used to be able to) create and integrate with TrueCrypt [1], for example.

The TrueCrypt developers surprisingly stopped working on the software when support for Windows XP ended. They said that TrueCrypt wasn't secure because it might contain unfixed vulnerabilities.

The TrueCrypt team advised Windows users to switch to BitLocker (the encryption built into Windows). Integrated Windows encryption is certainly not an option for Linux users and security-conscious users. However, Tomb [2] is an interesting alternative for former TrueCrypt users that builds on established Linux standards.

Installing Tomb

Tomb uses the dm-crypt [3] cryptography module, which is integrated into the Linux kernel's device mapper. It also relies on the LUKS [4] extension, which adds a header with information about encryption to the encrypted space, thus making it easier to handle the encrypted data.

Users can, for example, create multiple keys and change or delete them as needed, without having to rewrite the encrypted data from scratch. As a simple shell script, Tomb combines various actions into one small program, without the program needing to reinvent the encryption wheel. Any Linux system with kernel 2.6 or later will have the necessary tools out of the box.

Although the program only has a few dependencies, you are unlikely to find Tomb in the major distributions' repositories right now. In other words, you generally need to install manually, although this is not difficult.

Tomb provides an installation guide on the project page [5]; for Arch Linux, you will find Tomb in the AUR [6]. To install it, you will need to load the necessary dependencies via the package manager (Listing 1 gives you a how-to for Debian/Ubuntu), then load the program's source code in the form of the Tomb <Version>.tar.gz file onto your computer [7] and extract the archive (Listing 2). Typing make install in the code directory then installs the program on your system.

01 $ sudo apt-get install zsh sudo gnupg cryptsetup pinentry-curses
02 ### For graphical dialogues with PIN entry
03 $ sudo apt-get install pinentry-gtk2  ### With Gnome, Unity or Xfce
04 $ sudo apt-get install pinentry-qt4   ### With KDE
05 ### Optional dependencies
06 $ sudo apt-get install dcfldd qrencode steghide swish-e wipe

01 $ tar xf Tomb*.tar.gz
02 $ cd Tomb*
03 $ sudo make install
04 $ tomb -v
05 Tomb 2.1 - a strong and gentle undertaker for your secrets
06
07 Copyright (C) 2007-2015 Dyne.org Foundation, License GNU GPL v3+
08 This is free software: you are free to change and redistribute it
09 For the latest source code go to <http://dyne.org/software/tomb>
10 [...]

Gravedigger

After the installation, prepare a virtual tomb for your data; this will hold the data to be encrypted later on. In Tomb-speak, this is referred to as "digging a tomb." Launch Tomb from a terminal using the dig command and the -s <size in MB> option, plus the name of the encrypted container to be created (Listing 3).

01 $ tomb dig -s 100 secret.crypt
02 tomb  .  Commanded to dig tomb secret.crypt
03 tomb (*) Creating a new tomb in secret.crypt
04 tomb  .  Generating secret.crypt of 100MiB
05 100 blocks (100Mb) written.
06 100+0 records in
07 100+0 records out
08 -rw------- 1 username users 100M 11. Aug 16:23 secret.crypt
09 tomb (*) Done digging secret
10 tomb  .  Your tomb is not yet ready, you need to forge a key and lock it:
11 tomb  .  tomb forge secret.crypt.key
12 tomb  .  tomb lock secret.crypt -k secret.crypt.key

The size needs to be at least 10MB. You can, of course, enlarge the Tomb later, but you cannot shrink it. The encrypted data tomb should then be in the current directory.

A container is not very useful if you do not have a key file. You can create one by launching Tomb a second time and using the forge command (Listing 4) – Tomb outputs the relevant notes at the end of the dig command. However, the program needs root privileges to create the key file; the process may also take a while – depending on the size of the container and speed of the system.

01 $ tomb forge secret.crypt.key
02 tomb  .  Commanded to forge key secret.crypt.key
03 mkdir: the ?/home/username/.gnupg? directory cannot be created: The file already exists
04 tomb  .  Commanded to forge key secret.crypt.key with cipher algorithm AES256
05 tomb  .  This operation takes time, keep using this computer on other tasks,
06 tomb  .  once done you will be asked to choose a password for your tomb.
07 tomb  .  To make it faster you can move the mouse around.
08 tomb  .  If you are on a server, you can use an Entropy Generation Daemon.
09 256 blocks (0Mb) written.
10 256+0 records in
11 256+0 records out
12 tomb (*) Choose the  password of your key: secret.crypt.key
13 tomb  .  (You can also change it later using 'tomb passwd'.)
14 [GNUPG:] PROGRESS need_entropy X 60 120
15 [GNUPG:] PROGRESS need_entropy X 120 120
16 [...]
17 [GNUPG:] PROGRESS need_entropy X 60 120
18 [GNUPG:] PROGRESS need_entropy X 120 120
19 [GNUPG:] NEED_PASSPHRASE_SYM 9 3 2
20 [GNUPG:] BEGIN_ENCRYPTION 2 9
21 [GNUPG:] END_ENCRYPTION
22 tomb  .  Key is valid.
23 tomb  .  Done forging secret.crypt.key
24 tomb (*) Your key is ready:
25 -rw------- 1 username users 531 11. Aug 16:27 secret.crypt.key

Tomb also refuses to execute the command if a swap partition is active (Listing 5). The problem is that you cannot stop the data you want to encrypt ending up in the system's unencrypted cache. You therefore need to switch off the cache using swapoff -a – or force the action using the -f option.

01 $ tomb forge secret.crypt.key
02 tomb  .  Commanded to forge key secret.crypt.key
03 tomb  .  An active swap partition is detected...
04 [sudo] password for username: ***********
05 tomb [W] This poses a security risk.
06 tomb [W] You can deactivate all swap partitions using the command:
07 tomb [W]  swapoff -a
08 tomb [W] [#163] I may not detect plain swaps on an encrypted volume.
09 tomb [W] But if you want to proceed like this, use the -f (force) flag.
10 tomb [E] Operation aborted.
11 $ sudo swapoff -a

Turning the Key

Next, seal the data tomb using the key file you just created; Tomb again requires root privileges for this step. The corresponding option is simply called lock ; enter the name of the container and the key file – together with the -k button – as parameters (Listing 6).

01 $ tomb lock secret.crypt -k secret.crypt.key
02 tomb  .  Commanded to lock tomb secret.crypt
03
04 [sudo] Enter password for user username to gain superuser privileges
05
06 tomb  .  Checking if the tomb is empty (we never step on somebody else's bones).
07 tomb  .  Fine, this tomb seems empty.
08 tomb  .  Key is valid.
09 tomb  .  Locking using cipher: aes-xts-plain64:sha256
10 tomb  .  A password is required to use key secret.crypt.key
11 tomb  .  Password OK.
12 tomb (*) Locking secret.crypt with secret.crypt.key
13 tomb  .  Formatting Luks mapped device.
14 tomb  .  Formatting your Tomb with Ext3/Ext4 filesystem.
15 tomb  .  Done locking secret using Luks dm-crypt aes-xts-plain64:sha256
16 tomb (*) Your tomb is ready in secret.crypt and secured with key secret.crypt.key

The whole thing is now flavored with an additional password, which Tomb requests via a GTK or Qt window, or using ncurses (Figure 1) on a system without an X server. Tomb then immediately formats the container using Ext4 as the filesystem. You can change the password later if necessary using tomb passwd <secret.crypt.key> .

Figure 1: If you create or open an encrypted container, Tomb will request the password for the key file when available from a graphical window.

The encrypted container is now sealed and secured on your hard drive; you will need to open it to write data. Run Tomb again in the terminal and, using open this time, tell the program to unlock the container using the corresponding key file (Listing 7).

01 $ tomb open secret.crypt -k secret.crypt.key
02 tomb  .  Commanded to open tomb secret.crypt
03 tomb  .  Valid tomb file found: secret.crypt
04 tomb  .  Key is valid.
05 tomb  .  Mountpoint not specified, using default: /run/media/username/secret
06 tomb (*) Opening secret on /run/media/username/secret
07 tomb  .  This tomb is a valid LUKS encrypted device.
08 tomb  .  Cipher is "aes" mode "xts-plain64:sha256" hash "sha1"
09 tomb  .  A password is required to use key secret.crypt.key
10 tomb  .  Password OK.
11 tomb (*) Success unlocking tomb secret
12 tomb  .  Checking filesystem via /dev/loop0
13 fsck from util-linux 2.26.2
14 secret: clean, 11/25168 files, 8831/100352 blocks
15 tomb (*) Success opening secret.crypt on /run/media/username/secret

Tomb additionally requires root privileges for this step and will deny the action if the program finds an active swap partition. So, switch them off again and force the action using -f .

You will find the container's data in /run/media/<user>/<encrypted_container> , or wherever your distribution mounts disk drives. This directory should be used as if it is a conventional disk. If your system only allows root access to the data, assign the files in the container to the user account using sudo chown -R $user: <path/to/container> . If required, you can also retrieve the details of the mounted Tombs using tomb list (Listing 8).

01 $ tomb list
02 tomb  .  [secret] open on /run/media/username/secret using (rw,nodev,noatime,data=ordered)
03 tomb  .  [secret] open since Do 13 Aug 2015 10:39:18 CEST
04 tomb  .  [secret] open by username from /dev/pts/0  on ubele
05 tomb  .  [secret] size 91M of which 22M (26%) is used: 63M free
06 tomb  .  [secret] hooks tomb.secret.1439455158.loop0 on /home/username/.mozilla
07 tomb  .  [secret] hooks tomb.secret.1439455158.loop0 on /home/username/.thunderbird
08 tomb  .  [buried] open on /run/media/username/buried using (rw,nodev,noatime,data=ordered)
09 tomb  .  [buried] open since Do 13 Aug 2015 10:43:02 CEST
10 tomb  .  [buried] open by username from /dev/pts/0  on ubele
11 tomb  .  [buried] size 91M of which 1,6M (2%) is used: 83M free

If you don't need the open encrypted container any longer, close it using tomb close and unmount the directory. Save all the open data from the encrypted directory first and close the corresponding applications. If processes are still using the container or speed is of the essence, just slam shut all the doors to the open Tombs regardless of the consequences using tomb slam all (Listing 9).

01 ### Normal case
02 $ tomb close
03 ### Closes all applications accessing a Tomb
04 ### and locks all mounted Tombs
05 $ tomb slam all

Tomb in Practice

You will not want to reveal the fact that the secret.tomb container or the secret.tomb.key key relate to encrypted data (See also the "Bind Hooks" box). Also, the key and lock should not be on the same disk, and certainly not in the same directory. You should choose inconspicuous file names and move the key, for example, to a USB flash drive or load it from another computer via SSH. If you precede the Tomb call with a blank character, the command will not usually appear in the shell history.

01 $ mv ~/.thunderbird  /run/media/username/secret
02 $ mv ~/.mozilla  /run/media/username/secret
03 $ cat /run/media/username/secret/bind-hooks
04 .thunderbird .thunderbird
05 .mozilla .mozilla
06 path/in/tomb path/in/home
07 $ tomb close
08 $ tomb open secret.tomb -k /tmp/secret.tomb.key
09 $ mount | grep loop
10 /dev/mapper/tomb.secret.1439392070.loop0 on /run/media/username/secret type ext4 (rw,nodev,noatime,data=ordered)
11 /dev/mapper/tomb.secret.1439392070.loop0 on /home/username/.thunderbird type ext4 (rw,nodev,noatime,data=ordered)
12 /dev/mapper/tomb.secret.1439392070.loop0 on /home/username/.mozilla type ext4 (rw,nodev,noatime,data=ordered)

The example in Listing 11 camouflages the container as a VDI file for VirtualBox. If you store this file in the appropriate folder, it will be virtually unnoticeable – security by obscurity.

01 ### General
02 $ ssh user@example.net 'cat secret.tomb.key' | tomb open secret.tomb -
03 ### With obscured file names
04 $ ssh user@example.net 'cat windows-7-disk1.vdi.key' | tomb open windows-7-disk1.vdi -

However, you should make sure that the file can be quickly identified as an encrypted container based on the LUKS header (Listing 12) and that the designation of the files is maintained according to the <Name><Extension> and <Name>.<Extension>.key type.

01 $ file windows-7-genuine.vdi
02 windows-7-disk1.vdi: VirtualBox Disk Image, major 1, minor 1 (<<< Oracle VM VirtualBox Disk Image >>>), 8589934592 bytes
03 $ file secret.tomb
04 secret.tomb: LUKS encrypted file, ver 1 [aes, xts-plain64:sha256, sha1] UUID: a0164b11-11e7-4115-b402-056a13d511ef
05 $ file windows-7-disk1.vdi
06 windows-7-disk1.vdi: LUKS encrypted file, ver 1 [aes, xts-plain64:sha256, sha1] UUID: a0164b11-11e7-4115-b402-056a13d511ef

Steganography would be another option for hiding the key inconspicuously or directly on your own system [8]. Using this method, you inconspicuously embed information in other data. Hiding secret information in images is a common approach.

Tomb supports this process, assuming that the steghide program is in place on your system as an optional dependency. You can bury the specified key in the selected file using the bury command. Next, delete the original key file secret.tomb.key from the computer (preferably using wipe ) or hide it on a USB flash drive that you then also hide for added security. You can dig up the key from the image file again if necessary using exhume (Listing 13).

01 $ tomb bury bild.jpg -k secret.tomb.key
02 tomb  .  Key is valid.
03 tomb (*) Encoding key
04 -----BEGIN PGP MESSAGE-----
05 Version: GnuPG v2
06
07 jA0ECQMClZs6+luhEoHm0sB6AUdMrLbJeTstE1ZVTeyj8KkTEx68ywMdMvVq9WLH
08 [...]
09 TvIdts3sqcABahEMbjKy8mW8T95v6x8tbnzFs6TRprAkhEhbdt1V3qZ5zBw=
10 =BB4j
11 -----END PGP MESSAGE-----
12  inside image bild.jpg.jpg
13 tomb  .  Please confirm the key password for the encoding
14 tomb  .  A password is required to use key secret.tomb.key
15 tomb  .  Password OK.
16 Embed standard input in "bild.jpg"... done
17 tomb (*) Tomb key encoded successfully into image bild.jpg
18
19 $ tomb exhume bild.jpg -k secret.tomb.key
20 tomb  .  Trying to exhume a key out of image bild.jpg
21 Extracted data were written following "secret.tomb.key".
22 tomb (*) Key successfully exhumed to secret.tomb.key.

If you don't trust electronic memory to keep your key safe permanently, Tomb offers another possibility: You can write the key file into a QR code using the engrave option. You can then print out and file the code (Listing 14).

01 $ tomb engrave -k secret.tomb.key
02 tomb [W] The key seems invalid or its format is not known by this version of Tomb.
03 tomb [W] Attempting key recovery.
04 tomb (*) Rendering a printable QRCode for key: secret.tomb.key
05 tomb (*) Operation successful:
06 -rw-r--r-- 1 username users 2,6K 12. Aug 15:50 secret.tomb.key.qr.png

If necessary, you can read the code again using a scanner or, even more simply, using a smartphone and a corresponding app and then copy the decoded key to your computer. There you can open the sealed Tomb using the usual commands.

Figure 2 shows the QR code generated from a key and the key embedded in an inconspicuous image using steganography methods – as you can see, there is nothing unusual about either.

Figure 2: The image contains a key hidden in the image data using steganography. You could print out the QR code with the Tomb key and thus save it offline.

Conclusions

Tomb makes dealing with encrypted containers really easy. The well-conceived syntax is restricted to a few commands and buttons in everyday life. The approach of using standard Linux tools ensures trusted underpinnings – thus avoiding the need for Tomb to reinvent the encryption wheel.

As is so often true with encryption, the devil is in the details. Bad practices all too often thwart good approaches. Avoid keeping keys and containers on the same system – or at least store the key on a USB flash drive. You also need to make sure that the shell history doesn't reveal anything about the use of an encrypted container.

There are also restrictions in terms of portability: Kernel 2.6 or later are now available on almost all Linux systems. However, you will need administrative privileges on the computer for most Tomb actions, even to open a Tomb for example.

This means users who work with Linux but do not manage the system themselves cannot use the tool. Users with Mac OS X or Windows remain completely sidelined. However, on the project page, the developers carefully imply that there are at least plans for a Windows version.

Some users may miss a graphical interface for mounting and managing Tombs. There are currently many useful approaches, such as a small GTK program for the system tray or a GUI written using Python. They were not totally impressive in the test, however. zuluCrypt [9], which – based on the information provided by the developer – at least supports opening and closing Tombs, currently makes the best impression (Figure 3).

Figure 3: zuluCrypt supports use of containers and partitions encrypted with TrueCrypt and VeraCrypt as well as dm-crypt and LUKS.

It supports the use of containers and partitions encrypted with TrueCrypt and VeraCrypt as well as dm-crypt and LUKS. However, it is pretty easy to integrate Tomb into your own scripts and thus make operations more intuitive, without needing graphical programs.