Disk encryption in Linux

Protection of privacy is a topic with growing importance. I've been exploring and testing various options on how to deploy encrypted disks in Gentoo linux.
There are quite a few blogs and wiki articles about how to set up encrypted disks with DM-Crypt and how to configure kernel to support for device mapper and cryptographic API support. Also the homepage of cryptsetup tool contains a lot of information, so I would focus on topics which are not that well covered.

Cryptography algorithms in Linux

The question which algorithm to choose to protect your precious is always difficult, so I'll try to summarize what is available (tested on kernel 3.10 and cryptsetup 1.60) and you can select the combination based 

You can find out what is available on your system by using cat /proc/crypto. 

If you want to see what performance each has, there is a way to test them with cryptsetup benchmark.

In order to use them in connection with cryptsetup command, it is necessary to combine them into a crypt target string:

     cipher[:keycount]-chainmode-ivmode

example: 

aes:256-xts-plain
serpent-cbc-plain
aes-cbc-essiv

The size of the key can be also specified as separate option (-s), but if omitted the default size is 256 bits. It is also important to note that key size should be multiplication of 8 (we're dealing with bytes of storage..).
If there is no crypt target option (-c) specified, the default values that are compiled in can be displayed with cryptsetup --help command.
As for choosing the possible crypt target string here are some of the options (they depend on the kernel settings compiled in):

Encryption algorithms

As the number of supported ciphers is growing, here's the list of those available in recent linux kernels:

• AES
• Blowfish
• Twofish
• DES, 3DES
• Anubis
• Khazad
• Serpent
• ARC4
• Camellia
• CAST5,6
• Salsa20
• TEA,XTEA,XETA

Choosing one is highly dependent on what security risk is to be covered  by it and what is the usability expectancy of the system that would utilize that encryption.

Block chaining algorithms

• ECB (Electronic CodeBook)
• CBC (Cipher Block Chaining)
• PCBC (Propagating CBC)
• CTR (Counter)
• XTS (XEX-based Tweaked Codebook)

Initialization vector generators

• plain (initial vector is the 32-bit version of the sector number, padded with zeros if needed)
• plain64 (as above, but 64-bit version, so large disks can be used)
• ESSIV ( "encrypted sector|salt initial vector", the sector number is encrypted with the bulk cipher using a salt as key.The salt is derived from the bulk cipher's key via hashing.)
• BENBI (64-bit "big-endian 'narrow block'-count", starting at 1)
• null (IV is always zero)
• LMK (Compatible implementation of the block chaining mode used by the Loop-AES block device encryption system)
• TCW (Compatible implementation of the key seeded IV with additional whitening (to CBC mode))

Digest algorithms

• SHA1, SHA256, SHA512
• Tiger
• RIPEMD-128,160,256,320
• Whirlpool
• GHASH
• MD4, MD5

DM-Crypt with LUKS

The most common linux disk encryption is linux unified key setup (LUKS), where the encryption key is password or key encrypted and stored in one of the slots on the disk.

This way of operation offers flexibility of having several ways to decrypt the disk, so several people can have their private passwords used without the need of sharing it with others as well as offers revocation possibility without re-encrypting the disk again.

Create the disk

This command initializes the LUKS partition on the disk.

cryptsetup luksFormat [disk device] [device-mapper name]

Use the disk

cryptsetup luksOpen [disk device] [device-mapper name]

Remove the disk

cryptsetup luksClose [device-mapper name]

Other commands

There are also various key management commands like luksAddKey, luksRemoveKey, luksChangeKey or luksKillSlot, which modify the LUKS partition.

For troubleshooting there are other commands, which might be useful like isLuks and luksDump which show the content of the LUKS partition.

To do backups of luksSuspend or luksResume to pause writing to the disk (to perform a backup) or luksHeaderBackup and luksHeaderRestore to back-up the LUKS partition.

Plain DM-Crypt

For those who don't like to have key (although encrypted) stored on the same device, there is a possibility to use the plain DM-crypt.

Plain format has no metadata on disk, reads all parameters from the commandline, derives a master-key from the passphrase and then uses that to de-/encrypt the sectors of the device, with a direct 1:1 mapping between encrypted and decrypted sectors.

Open the disk

This command specifies the key with which disk is to be decoded with (no formatting or initialization needed)

cryptsetup open [disk device][device-mapper name]

Remove the disk

In order to gracefully remove the disk, the cryptsetup remove [device-mapper name] can be used.

Troubleshooting

Although plain mode doesn't have as powerful command set as LUKS mode, with cryptsetup status [device-mapper name], it displays some basic information about the opened disk.

Full disk encryption

Now the "full" disk encryption is a bit more complicated, as this requires to build a /boot partition with all the tools required to decrypt and mount the root partition.
Gentoo provides a documentation on their wiki page, but there is a much easier way than generating initramfs with scripts:

1. Install system with stage3 (as well as emerge genkernel; grub)
2. Configure kernel and store configuration in file other than /usr/src/linux/.config
3. execute genkernel --luks --kernel-config [path to config file] --install all
4. generate grub config with grub2-mkconfig -o /boot/grub/grub.cfg
5. ensure that /boot/grub/grub.cfg contains appropriate options for loading the kernel (e.g. crypt_root=[encrypted disk] and real_root=[DM partition to mount])

There is also a possibility to do it with key being stored on USB device, in which case the grub config has to also contain options like root_keydev=[USB mount point] and root_key=[file containing the key].

Conclusion

When considering disk encryption you have to consider the following security requirements:

• threat agent (partner/co-worker; thief; corporation; government) and value of the data stored on the disk
• other security controls protecting the disk (physical security; access control; operational security; etc.)
• loss mitigation or recovery options ( data recovery from other sources or off-site backup; re-installation of the system)

And also think about what impact it can have on usability of the system:

• How often decryption code has to be entered
• Encryption overhead on system performance
• Overhead when doing system upgrade (e.g. new kernel installation or OS upgrade)
• Overhead for system maintenance (disk replacement or backups)

After good consideration and evaluation of chosen encryption and type of deployment, installation and configuration is quick and painless. DM-crypt is very stable and backwards compatible, so it can be used on operational systems running 24/7. And with current internet or political situation it should surely be considered when building new systems for home or work.

Dead man's Switch

I've been thinking in the past about how to ensure operational security when dealing with risk of loss of life, but after reading the creative story of Snowden’s dead man's switch solution I decided to put my ideas down for consideration.

The tactic is based on fact that the action to the author is more damaging than letting him be.
To create a dead man's switch protection, there are two main points to deal with:

Package

First thing to consider is if the package has sufficient importance to the threat actor, which would avert the action they might want to perform. If the data or asset has no importance to threat actor this tactic would not minimize the risk.
Next thing to consider is how to maintain the package value (if it is not deteriorating in time by itself) to the threat actor.
The data or asset, which is going to be exposed, damaged or deleted has to be either 

• very well hidden (preferably not even the author of the dead man's switch should know its location) or 
• it has to be copied and distributed, so any containment is not feasible.

In order to prevent premature exposure (in case of massive distribution), strong encryption might be a good idea.

The option to hide it is a bit more tricky, as that can’t be done by friends or anybody who can be related to the author, as that is easily traceable. Having several transfers from one person to another with different types of transfer (personal / delivery to PS box / fake address delivery / dead drop box) should make tracking the location sufficiently difficult, even though not impossible.

Trigger

The event, that should trigger the action to the package can either be 

• news about author or similar public event, or 
• it can be lack of “proof of life” signal (meaning author didn’t update his/her status on pre-defined website or has not sent such message in agreed interval)

There are also more complex possibilities, where the package action has to be performed by several people (e.g. decryption with several keys in correct order).

Another multi-person trigger mechanism might be to have extra role of observer, who will issue the signal to the package via indirect means (news/publication/website status/email/etc.)

With several layers of encryption, there is also a possibility of having multi-stage trigger, where some parts of the package get exposed, for example in case of arrest and later in case of disappearance or death.

Validation

No matter how complicated solution is chosen, trying it out is always a good idea, as flawed solution doesn’t provide the same effect as a feasible one.

Testing the distribution of the package is probably more important than the trigger, because if it can be tracked or contained before the trigger is executed, it would miss its purpose.

But in the end, what counts is the fact that the threat actor believes it is a feasible and can significantly affect him, thus minimizing the risk to the author of the dead man's switch.