Encrypt your important files using Tomb

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

Listing 6

Seal the Tomb

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

Listing 7

Unlock the Container

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

Listing 8

Using tomb list

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

Listing 9

Using tomb slam all

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.

Bind Hooks

Important data is often found both in document formats, such as .txt or .odt, which can be easily and specifically moved to an encrypted container, and in the settings and data of programs, which the respective application organizes in its program folder. For example, the Thunderbird email client stores all mail and contacts in the ~/.thunderbird folder. The same applies to Firefox where all bookmarks and other private data are found in the ~/.mozilla directory. Using bind hooks, you can easily move this data to an encrypted Tomb.

Create the Tomb in the usual way and mount it on your system. Then, close the desired applications and move their program data from your home directory to the mounted Tomb. Use your preferred editor to create a new text file named bind-hooks in the Tomb and enter the directories to be linked in the form of a simple table (Listing 10). The first relative path is in the Tomb container; the second follows in the home directory. In the simplest case. Simply repeat the folder names.

Now, close the Tomb and create the configuration folder in your home directory again. Tomb will be missing a mount point later if you don't create that folder. Simply restart the respective applications, or create the folder manually in your home directory. The next time you open the container, Tomb will mount the encrypted data over that in the normal home directory. This way, you can organize two databases at once: your non-critical private emails and bookmarks for one, and – after mounting the Tomb – data designated for your eyes only. If you unmount the Tomb again, the innocuous data will appear again automatically – once the programs are restarted.

Listing 10

Enter Directories

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.

Listing 11

Camouflage the Container

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.

Listing 12

Using LUKS Header

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

Listing 13

Exhume Key

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

Listing 14

Print the Code

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.

« Previous 1 2 3 Next »