Full Disk Encryption and Encrypted Images
- 1 Full Disk Encryption on the Host
- 1.1 Protection Against Powerful Adversaries
- 1.2 Protection Against Lesser Adversaries
- 2 Encrypted Guest Images
- 3 Footnotes
- 4 License
Full Disk Encryption on the Host
|As outlined on the Warning page, Whonix has not been designed as an amnesic operating system. Traces of the installation and user activities will be written to disk. |
Protection Against Powerful Adversaries
To protect against theft or robbery of personal information or data, users should apply FDE (Full Disk Encryption) on the host, and power off their computer when exposed to higher-risk situations like traveling. Laptop users should temporarily remove the laptop battery 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, as the swap partition is encrypted in the default FDE configuration for various platforms (like Debian), provided the user did not change anything.
Users should follow the standard advice for picking strong and unique passwords, so that the password cannot be feasibly brute-forced. If possible, computers should never be left unattended.
|It is safest to assume that a machine has been compromised after any unauthorized physical access.|
If unauthorized access is strongly suspected or confirmed, the hardware should not be trusted or used after it is back in the user's possession. This scenario is only relevant to a smaller subset of users 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 below would help.
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 users can power-off the computer immediately with the Magic SysRq key feature. This is invoked by pressing the key combination:
o (lower-case letter). On bare-metal linux systems, the FDE passphrase is prompted after rebooting.   The magic key feature does not work on Qubes hosts because the Xen hypervisor does not recognize these commands. 
USBKill is an anti-forensics script written in the aftermath of the SilkRoad trial. Its purpose is to trigger protection events that prevent adversaries from siphoning files, installing malware, or running a mouse jiggler. The script creates a white-list of allowable USB devices. If anything else is plugged into the machine, the RAM is erased and the computer is immediately shutdown.
USBKill can also be configured to exclude all devices from being attached. In another high-security configuration, a white-listed flash drive serves as a key, and must be in the USB port at all times. If the flash drive is forcibly removed, the program will initiate the desired routines.  
Protection Against Lesser Adversaries
The reader is reminded that 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 thosed listed below, but the topic is a rabbit hole (see footnotes in this section).  Plausible deniability and FDE are also useless if the user is subject to physical abuse by a captor.
Advice for Solid-state Drives and USB Storage
|In the case of flash-based storage like solid-state drives (SSDs) and USBs, the only way to protect data is to never store it unencrypted in the first place!|
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: a user 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.
Nuke Patch for cryptsetup
|Under most emergency conditions, the user will not have enough time to reboot the computer and enter the dead-man switch passphrase.|
Supplying the dead-man switch as the "real passphrase" to the interceptors of the machine is unlikely to be an effective strategy. It is standard forensics procedure to create multiple images of the drive beforehand.
Separate /boot Partition
When FDE is used on the host, it is inadvisable to keep any unencrypted files on that same physical media. High-risk users are recommended to move the /boot partition to a separate USB media. The bootloader (Grub) should then also be installed on the separate USB. To read more on this subject, see Pwning Past Whole Disk Encryption.
Install the GNOME disk utility on the host to easily encrypt removable storage before use, or to change the passphrase of a LUKS enabled system.
In a terminal, run.
sudo apt-get install gnome-disk-utility
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.
Encrypted Guest Images
|This encrypted images chapter is mostly theoretical at this point, because it contains numerous open research questions and is currently unsupported.|
The greatest security benefit comes from applying full disk encryption on the host because that is the only place where it is most effective. Nevertheless, for the interested reader this section makes recommendations to deal with the following threat model:
- The host is running when an adversary gets access to it, or the host is unencrypted.
- The VM is powered down (otherwise the adversary would already have access to it).
The following security considerations are based on modified quotes by Iszi from the answer posted on security.stackexchange.com, which was a user contribution to stackexchange, licensed under cc by-sa 3.0 with attribution required.
Full Disk Encryption within the Virtual Machine
When using FDE within the VM, never save (suspend/pause) the VM machine state, but instead shut it down completely. If this advice is ignored, the saved machine state could be stored outside of the encrypted image. This includes a RAM dump, which contains the encryption key required to decrypt the image. Upon resuming the VM, that stored file is not necessarily securely deleted, since it is virtualizer-specific. 
While the VM is running, users should not use the host system's sleep, suspend, or hibernate functions. Similar to the first scenario, these actions leave a RAM dump on disk, but this time it belongs to the host. This also contains sensitive data, such as encryption keys.
Virtual Machine Files in an Encrypted Container
VM files can also be stored in an encrypted container, such as a LUKS container. Newer and native support for LUKS encryption of disk images is available as of libvirt 2.10  The same precautions should be taken as outlined in the previous section, as the risks equally apply.
FDE within the VM, LUKS encrypted containers for VM images, and FDE on the host can all be used independently, or in conjunction. However, increasing the layers of encryption may begin to significantly degrade performance. End modified quote by Iszi.
Other Security Considerations
Encryption is an area with many pitfalls. The user should also consider the following:
- KVM: It is not expected that KVM guests could access data from other process' memory pages via memory ballooning, since KVM guests are Linux processes and subject to Linux memory allocation rules. 
- Memory Dumps: These are caused by BSOD or kernel crashes, and can leave unintended traces on the host.
- Powered-down VMs: After a VM has shutdown, the RAM that previously contained the VM's encryption key might not have been wiped yet. Memory pages belonging to a terminated process do not have their contents wiped (zeroed) until they are about to be used by another process.    
- Swap: An encrypted swap provides no protection so long as the host is powered up, because the key is still in RAM.
- Disabling Swap: This action requires a special, secure wiping of the existing swap. It is safer to have never used swap before.
- Xen: Memory ballooning in Xen creates privacy concerns because it exposes the memory contents of other VMs if ballooning is enabled. 
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, without host FDE.
Open Security Research Questions
The following questions and configurations require further research:
- With swap and crash dumps disabled, it is unknown whether the virtualizer writes parts of the VM's RAM contents to the disk. TODO: Specifically ask virtualizer vendors about this possibility.
- Potential setup configurations:
- Theoretically, a fullly encrypted operating system (currently: Debian) could be installed inside a VM and Whonix could be built using
--target rootinside another VM. This is analogous to the physical isolation model, but secure VM settings would be missing (similar to Manually Create Whonix VM Settings).
- An encryption feature could be added to grml-debootstrap and/or the Whonix build script. There was an attempt to do that, but this effort has stalled.
- cryptsetup-reencrypt could be used, allowing for the shipping of encrypted Whonix images. The master key and the password (potentially blank) would be known to the public at first. Later, users would use cryptsetup-reencrypt to fix the master key and password, that is, to make the encryption effective.
- Theoretically, a fullly encrypted operating system (currently: Debian) could be installed inside a VM and Whonix could be built using
- Until in-RAM execution of disposableVMs is implemented in Qubes-Whonix, this threat is not easily mitigated.
- For example, this can be done quickly if the flash drive is attached to the user's wrist via a lanyard.
- cryptsetup FAQ - Section: 5.19 What about SSDs, Flash and Hybrid Drives?
- In the case of VirtualBox, the file could end up in the folder ~/.virtualbox. A definitive answer requires further research.
- https://www.techopedia.com/definition/30466/memory-ballooning : "Memory ballooning is a memory management feature used in most virtualization platforms which allows a host system to artificially enlarge its pool of memory by taking advantage or reclaiming unused memory previously allocated to various virtual machines."
- https://security.stackexchange.com/a/42186 : "Linux zeroes out (i.e. fills with zeros) all pages of memory not when they are released, but when they are given to another process. Thus, no process may obtain data excerpts from another process. However, the pages will retain their old contents until they are reused."
- The threat is similar to cold boot attacks, but in this case it might even be a "warm" attack, because under this threat model, the machine and RAM is still powered. PAX_MEMORY_SANITIZE and its KSPP successor may mitigate this, but at the cost of a non-trivial performance hit.
- http://docs.openstack.org/security-guide/content/data-privacy-concerns.html : Xen explicitly assigns dedicated memory regions to instances and scrubs data upon the destruction of instances (or domains in Xen parlance). KVM depends more greatly on Linux page management; A complex set of rules related to KVM paging is defined in the KVM documentation. It is important to note that use of the Xen memory balloon feature is likely to result in information disclosure. We strongly recommended to avoid use of this feature.
- Live OS systems are designed to not leave traces of user activity on disk.
Whonix Full Disk Encryption and Encrypted Images wiki page Copyright (C) Amnesia <amnesia at boum dot org>
Whonix Full Disk Encryption and Encrypted Images wiki page Copyright (C) 2012 - 2018 ENCRYPTED SUPPORT LP <email@example.com>
This program comes with ABSOLUTELY NO WARRANTY; for details see the wiki source code.
This is free software, and you are welcome to redistribute it under certain conditions; see the wiki source code for details.
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.