{{Header}} {{title|title= Encrypted VM Images }} {{#seo: |description=Full Disk Encryption (FDE) VM images are virtual machine images that have been encrypted with a full disk encryption mechanism. This article examines whether Full Disk Encryption (FDE) is a beneficial and secure method for safeguarding data stored in local virtual machines or cloud computing environments by exploring its advantages and security implications. |image=EncryptedImage43234.jpg }} {{fde-mininav}} {{Contributor| |status=stable |about=About this {{Code2|{{PAGENAME}}}} Page |difficulty=easy |contributor=[https://forums.whonix.org/users/HulaHoop HulaHoop] |support=[[Support]] }} [[File:EncryptedImage43234.jpg|thumb|200px]] {{intro| Full Disk Encryption (FDE) VM images are virtual machine images that have been encrypted with a full disk encryption mechanism. This article examines whether Full Disk Encryption (FDE) is a beneficial and secure method for safeguarding data stored in local virtual machines or cloud computing environments by exploring its advantages and security implications. }} = Encrypted Guest Images = {{mbox | type = notice | image = [[File:Ambox_notice.png|40px|alt=Info]] | text = This encrypted images chapter: * applies when using {{project_name_long}} inside VMs. * is mostly theoretical at this point, because it contains numerous open research questions and is currently [[unsupported|unsupported]]. }} The greatest security benefit comes from applying full disk encryption (FDE) [[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). {{Code2|The following security considerations are based on modified quotes by [https://security.stackexchange.com/users/953/iszi Iszi] from the answer posted on [https://security.stackexchange.com/a/29538 security.stackexchange.com], which was a user contribution to stackexchange, licensed under [https://creativecommons.org/licenses/by-sa/3.0/ cc by-sa 3.0] with [https://stackoverflow.blog/2009/06/25/attribution-required/ 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, the host system's sleep, suspend, or hibernate functions should not be used. 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 https://libvirt.org/formatstorageencryption.html#StorageEncryptionLuks 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. {{Code2|End modified quote by Iszi.}} == Other Security Considerations == Encryption is an area with many pitfalls; consider the following additional risks. '''Table:''' ''Additional Encryption Risks'' {| class="wikitable" |- ! scope="col"| '''Category''' ! scope="col"| '''Description''' |- ! scope="row"| Memory Dumps | These are caused by Blue Screen of Death (BSOD) or kernel crashes and can leave unintended traces on the host; see [[Core Dumps]]. |- ! scope="row"| 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. https://security.stackexchange.com/questions/42179/is-there-any-linux-distro-or-kernel-patch-that-wipes-a-process-memory-space-afte/42186#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.
 https://superuser.com/questions/894463/does-linux-zero-memory-released-by-applications/894936#894936 https://askubuntu.com/questions/721084/linux-overwriting-ram-with-zeroes-on-free/721207#721207 The threat is similar to [[Cold_Boot_Attack_Defense|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. [https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory PAX_MEMORY_SANITIZE] and its [https://github.com/GrapheneOS/linux-hardened/wiki#sanitize-all-freed-memory KSPP successor] may mitigate this, but at the cost of a non-trivial performance hit. |- ! scope="row"| Swap | An encrypted swap provides no protection so long as the host is powered up, because the key is still in RAM. Disabling swap requires a special, secure wiping of the existing swap -- it is far safer to have never used swap before. |- ! scope="row"| Virtualizer-specific Issues | * KVM: It is not ''expected'' that KVM guests could access data from other process' memory pages via [https://www.techopedia.com/definition/30466/memory-ballooning memory ballooning], since KVM guests are Linux processes and subject to Linux memory allocation rules. 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.
* VirtualBox: In the case of [[VirtualBox]], the file could end up in the folder {{Code2|~/.virtualbox}}. A definitive answer requires further research.
* Xen: Memory ballooning in Xen creates privacy concerns because when it is enabled the memory contents of other VMs are exposed. https://docs.openstack.org/security-guide/tenant-data/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.
 |} == Open Security Research Questions == The following questions 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. == Encrypted Images Setup == Installing Debian inside a VM first including full disk encryption (FDE) and using [[Distribution Morphing]] to [[Debian|morph Debian into {{project_name_short}}]] and result in an encrypted {{project_name_short}} VM image. == Potential Future Development == This is mostly theoretic and very most likely will not happen unless a volunteer contributes it which seems very unlikely. * An encryption feature could be added to [https://grml.org/grml-debootstrap/ grml-debootstrap] * https://github.com/grml/grml-debootstrap * https://packages.debian.org/search?keywords=grml-debootstrap * grml-debootstrap feature request: [https://github.com/grml/grml-debootstrap/issues/131 encrypted VM images support] * [http://www.coredump.us/index.php?n=Main.DebianEncryptedDebootstrap Debian Encrypted Debootstrap] {{project_name_short}} build script is a user build-steps.d/*_create-raw-image of grml-debootstrap. and/or the {{project_name_short}} build script. There was an [https://forums.whonix.org/t/whonix-container-encryption-options/193 attempt] to do that, but this effort has stalled. * [https://manpages.debian.org/{{Stable project version based on Debian codename}}/cryptsetup-bin/cryptsetup-reencrypt.8.en.html cryptsetup-reencrypt] could be used, allowing for the shipping of encrypted {{project_name_short}} images. The master key and the password (potentially blank) would be known to the public at first. Later on, cryptsetup-reencrypt would be used to fix the master key and password, that is, to make the encryption effective. = Conclusion = 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|Full Disk Encryption (FDE)]] is recommended instead. For further information about encrypted images, see [https://forums.whonix.org/t/how-useful-is-in-guest-encryption/1253 How Useful is In-Guest Encryption?] Readers interested in running {{project_name_short}} as a live OS should refer to [[Live Mode]]. = See Also = * [[Full Disk Encryption|Full Disk Encryption (FDE)]] * https://www.whonix.org/wiki/Dev/cloud = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]