Full Disk Encryption
|About this Full Disk Encryption Page|
- 1 Introduction
- 2 Debian Hosts
- 3 Removable Media
- 4 Encrypted Containers
- 5 Additional Measures
- 6 Advice for Solid-state Drives and USB Storage
- 7 Gnome Disks Utility
- 8 Footnotes
Encrypting Whonix VMs
The host of security considerations suggest that an unrealistic set of operational rules are required to defend the integrity of a purely encrypted guest image. Use of Full Disk Encryption is recommended instead.
Measures Against Non-violent Coercion
Even in relatively civilized states, the laws have been misconstrued to make civil liberties protections at the border weaker. In the case of the US, the Fourth Amendment can be violated at will by customs officers. This section assumes a scenario where one is compelled to divulge passwords without measures involving physical harm or indefinite imprisonment. In such situations it is always recommended to exercise your right to remain silent and to request a lawyer. Your devices will most likely be impounded and therefore backups of important data should be made beforehand.
- This EFF Guide provides advice and outlines your rights at the border. Tips like storing key material in the cloud should be ignored.
- A clever technique (page 3) proposed by OTR's designer, Ian Goldberg, uses Shamir's Secret Splitting Scheme to split a key-file and distribute it among trusted friends to make producing the key a physical impossibility.
- Cryptographer Bruce Schneier outlines a simpler variant of the above technique. A new random string is added as a password and then passed along to a trusted person, with the usual password being removed before crossing the border. After arriving, the key to access the drive can be retrieved and the original one re-added. 
If unauthorized access is strongly suspected or confirmed, the hardware should not be trusted or used after it is back in your possession. This scenario is only relevant to a small minority who are already targeted for physical surveillance. A sufficiently skilled adversary can infect it with spyware or sabotage it in a number of ways that are virtually undetectable. For example, malicious firmware could be installed to record all activities, or the machine rendered inoperable by bricking the hardware. In that eventuality, none of the measures outlined in this chapter will help.
Protection Against Powerful Adversaries
As noted above, advanced attackers have virtually limitless possibilities to infect a computer under their physical control, such as flashing low-level firmware or adding physical implants.
It may be possible to get plausible deniability on Linux hosts using methods other than those listed below, but the topic is a rabbit hole (see footnotes).  Plausible deniability and Full Disk Encryption (FDE) are also useless if subjected to physical abuse by a captor. A safer option is to have not left any discoverable data traces on a personal machine in the first place. The Whonix ™ grub-live package provides an amnesic feature on both Debian hosts and the Whonix ™ virtual environment. When used solely within a VM, it may provide adequate anti-forensic protection if various precautions are taken.
To protect against theft of personal information or data, FDE should be applied on the host, and the computer turned off when exposed to higher-risk situations like traveling. In the case of laptops, the battery should be temporarily removed after powering off. This ensures that the RAM chips are completely powered down and that any encryption key(s) in memory are erased.  Hibernation is also a safe alternative because the swap partition is encrypted in the default FDE configuration for various platforms (like Debian), so long as no changes were made.
Be sure to follow the standard advice for picking strong and unique passphrases, so they cannot be feasibly brute-forced. Also, computers should never be left unattended in untrusted venues.
Configuring FDE during system install is straightforward. The default cipher is AES-256 in XTS mode.
New Removable Media
Gnome Disks Utility creates LUKS partitions with AES-128 by default which is insufficient in event of quantum computers materializing. This has been successfully reported and fixed upstream as of February 2019,   but until it lands in Debian, an appropriately secure container must be manually created. Afterwards, unlock the device and format the internal filesystem as EXT4 in Gnome Disks.
First enumerate the device. They will usually be called 'sdb1', as sdaX is reserved for the system on default installs. To avoid confusion, only connect one removable device at a time.
# ls /dev/
Create a LUKS container and change the device name as needed, then follow the prompts.
# cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --use-random luksFormat <device>
Legacy Device Encryption Upgrade
It is safer to re-encrypt the device with a stronger key rather than performing a quick format that will otherwise leave the old/weaker header intact.
Encrypted containers have the twin advantages of flexibility and mobility of folders, allowing more files to be added on the fly without needing re-compression and re-encryption (as in the case of using GPG).
Zulucrypt is the Linux answer to encrypted containers, making use of the reliable LUKS disk encryption specification. It is compatible with encrypted tomb files and also capable of reading and creating Truecrypt / VeraCrypt containers. Note that Veracrypt containers only support a maximum password length of 64 characters, but LUKS has a maximum value of 32,767 (although a recently fixed bug had limited it to only 100 characters).  Until it is possible to use 20-word diceware passphrases to lock LUKS containers, it is recommended to use makepasswd to generate 43 character strings. These can then be pasted into a text file that is encrypted with GPG -- which does not have low character limits -- essentially creating a makeshift key file.
Containers grow dynamically as more data is added. Opened containers are mounted under
/run/media/private/user. More than one password may be added for access, making use of LUKS' key slots feature behind the scenes. 
Recommended Security Settings
Important Note: In order to have post-quantum resistance, the
aes.xts-plain64.512.sha512 option is recommended for 256-bit encryption (the encryption key-size is split in two with XTS mode).
To view the container header, run.
sudo cryptsetup luksDump --debug /home/user/<file_name>
With LUKS it is possible to nest containers of different encryption ciphers; for example, by placing a Serpent and Twofish container inside each other, wrapped in an outer AES one. Be sure to select the
.xts-plain64.512.sha512 variants in all cases. Each inner layer should be 1 MB less than the outer layer to allow space for each container's respective encryption header.
The plausible deniability feature is available with volume types
Normal+Hidden Truecrypt/Veracrypt. Veracrypt volumes support crypto-cascades as a feature, so manual nesting is unnecessary. However, be warned that Truecrypt/Veracrypt volume types only support AES-128. Plain dm-crypt containers with a non-zero offset can be used to provide hidden volumes according to Zulucrypt's manual. This is yet to be tested by Whonix ™ developers.
Table: Additional Protective Measures
|Erase LUKS Header||
This is a much quicker alternative to zeroing data on a HDD with Darik's Boot and Nuke (DBAN).   This is an effective measure on spinning HDDs where wiped data is confirmed to be destroyed. The OS only needs to read the LUKS header off disk once – not every single second. Wiping the header makes the disk impossible to unlock in the future. 
sudo cryptsetup luksErase /dev/sdXY
Alternatively, to accomplish the same goal without being prompted, run.
sudo dd if=/dev/zero of=/dev/sdXY bs=1M count=2
This will overwrite the first two megabytes of the partition
|LUKS Suspend Scripts||On Linux hosts, there is one interesting solution for the risks posed by a computer in a suspended state; luks-suspend scripts.  This approach has some limitations because it is not yet packaged for Debian, and it has only been tested in the Ubuntu and Arch distributions. As of 2018, luks-suspend and keyslot nuking (mentioned below) is being merged upstream. |
|Magic Key Feature||In an emergency, Non-Qubes-Whonix ™ is capable of powering-off the computer immediately via the Magic SysRq key feature. This is invoked by pressing the key combination: |
|Nuke Patch for cryptsetup||
|Separate /boot Partition||When FDE is used on the host, it is inadvisable to keep any unencrypted files on that same physical media. Those at high risk should move the /boot partition to a separate USB media and the bootloader (Grub) should also be installed on the separate USB. To read more on this subject, see Pwning Past Whole Disk Encryption.|
|TRESOR Kernel Patch||Another useful protection is the TRESOR kernel patch, which keeps the disk encryption key outside of RAM by storing it inside the CPU. TRESOR does have several limitations. It is only available for the x86 architecture, and it complicates software debugging by disabling DR registers for security reasons.  Moreover, a specialized attacker who can reverse engineer hardware designs is also capable of extracting secrets held in processor caches or specialized chips like TPMs.|
Advice for Solid-state Drives and USB Storage
Unlike hard-disk drives (HDDs), overwriting data on SSDs is no longer effective in wiping the disk.   For instance, it is insecure to rely upon a fast erase mechanism by overwriting the header and key-slot area. 
The most dire potential consequence is that old passwords are not erased, and for a significant period. Consider the following concrete example: someone changes their computer password because they noticed it was exposed to shoulder-surfing or CCTV. On a SSD, the old password is still retrievable and can be used to decrypt the master key and all data. The reason is that secure overwriting is only guaranteed with magnetic disks.
Wear-leveling mechanisms like TRIM also leak information about the filesystem that can aid forensics.      It is strongly recommended to keep TRIM disabled (the default) during Linux LUKS-encrypted installations.
Gnome Disks Utility
Gnome Disks utility provides a convenient way to manipulate LUKS container passphrases (including the host's) and the overlying filesystems. However, it should not be relied upon for encryption because it uses AES-128 as a hardcoded default   (as of Debian Stretch), which does not provide adequate post-quantum security. For encrypting removable media refer to this guide.
To install it, run.
sudo apt-get install gnome-disk-utility
- Until in-RAM execution of disposableVMs is implemented in Qubes-Whonix ™, this threat is not easily mitigated.
- https://security.stackexchange.com/questions/99906/can-ram-retain-data-after-removal https://security.stackexchange.com/a/100391
- DBAN also warns:
While DBAN is free to use, there’s no guarantee your data is completely sanitized across the entire drive. It cannot detect or erase SSDs and does not provide a certificate of data removal for auditing purposes or regulatory compliance. Hardware support (e.g. no RAID dismantling), customer support and software updates are not available using DBAN.
- In most emergency situations there will not be enough time to reboot the computer and enter the dead-man switch passphrase.
- For example, this can be done quickly if the flash drive is attached to your wrist via a lanyard.
- cryptsetup FAQ - Section: 5.19 What about SSDs, Flash and Hybrid Drives?
- As tested by Whonix ™ developer HulaHoop.
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation.
Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)