Notes on Full Disk Encryption in a Virtual Machine

• Risks and Threats
• Encryption Basics
• File Encryption
• Encrypted containers
• Key Escrow
• Full Disk Encryption
• Problems with FDE
• Virtual Machines
• Testing Virtual Machines with FDE
• Backups
• VPNs
• Conclusion
• Risks Revisited
• Links to other resources

Risks and Threats
A system used for processing sensitive data should take into account the following threats:

• Physical loss or theft of a computer or disk containing sensitive data.
• Access to data by a third party when a computer is sold or recycled.
• Copying of sensitive data in transit over an open network (e.g. open WiFi at an airport or hotel).
• Exfiltration of data from a computer infected with malware, such as keyloggers or backdoors.
• Access to data by a stranger while a computer is unattended.
• Access to sensitive data by persons who have the owner's permission to use the computer for an unrelated purpose.
• Exfiltration of sensitive data from a computer due to the normal operation of backup or online synchronization processes, which may copy the data over an insecure channel or to insecure media.
• Inability to access data due to the loss of encryption keys.
• Loss of data due to hardware failure of storage media.
• Loss of data due to human error (accidental erasure)
• Loss of access to data due to failure of the hardware used to read the media
• Loss of access to data due to obsolescence of the computer system used to read the media.
• Risk of "bricking" a system when installing FDE, e.g. from latent disk errors or operator error

Data encryption may be used to mitigate some of these threats.

Encryption Basics
The objective is to prevent unauthorized access to sensitive data, either electronically, or physically when a computer is unattended or is physically removed (stolen).
Data in transit may be protected by communications encryption e.g. SSL, while data at rest may be protected by file or disk encryption. Encryption is a method of encoding data with a key known only to authorized users, which may be typed in manually or held on a removable device such as a USB stick.

File Encryption

A data file may be encrypted using either a password or a random key. The password may be memorized; the random key may be stored on a removable device and stored securely. Typically, during this operation an unencrypted (plaintext) file is converted to a second, encrypted, file stored in a different area of the storage medium (usually a hard drive). The encrypted file may then be copied to an exchangeable disk or transferred across the network, and is secure unless an attacker knows the key.

However, the original plaintext file is still on the disk. If the file is deleted the data is still present and can be recovered. To securely erase the data, it must either be overwritten before deletion, or unused areas of the disk must be overwritten afterwards (which will take a very long time).
Most software is not written with security in mind, and may create a number of temporary files during operation. A simple text editor, for instance, will often copy the input file to a temporary file, make changes to the new file, then delete the original input file and rename the temporary file to the input file. The original (deleted) text is now recoverable from the disk.
A web browser may create hundreds of files under the user's profile - page cache, cookie files, history, downloaded fonts, add-ons etc.

Encrypted Containers

One solution to this problem of temporary files is to use an encrypted container. Just as a disk, or a portion of of disk (a partition), may have a filesystem created on it to contain files, so a binary file may have a filesystem created within it. For instance, a data DVD or floppy disk may have an bit-for-bit image copy made to a single file on a hard disk, and the filesystem inside this image may be mounted by the operating system to appear as a new, separate, storage device.

If the binary file used to make the image is encrypted, then you have an encrypted container. In practice, the operating system uses a special disk driver to encrypt and decrypt data as it is written to or read from the drive, so there is no need to repeatedly encrypt the entire container and no need for a plaintext version.

The encrypted container thus behaves like a disk. A password must be given when it is mounted, and then files and folders may be created inside, just as with a normal disk partition, USB stick, SD card etc.. If the working directory is set to the container disk, any files created during editing or by explicit save will automatically be encrypted. In the case of the Firefox web browser, if a user profile folder (created using "firefox -P") is placed in the container, all cookies, cached content etc. will be encrypted.

When the container is unmounted, the encrypted container file is secure and may be copied, transferred over an open network, or burned to a CD without exposing the data inside. The container file may be mounted on another computer using compatible software providing that the key is known.

Key Management and Escrow
While in conventional wisdom, passwords are never written down, encryption keys should be - as a guard against death, disaster, or just plain forgetfulness.
In most cases, computer passwords may be bypassed by an administrator, or by gaining physical access to the device. Encryption keys cannot be bypassed, so if lost, encrypted data becomes permanently inaccessible. The simplest method of management is to write the passphrase on a piece of paper, seal it in an envelope and place it in a physical safe where authorized persons may gain access at need. A more sophisticated scheme would use a random key for the symmetric encryption algorithm, which is then encrypted with multiple public keys. Keys may then be kept in escrow for disaster recovery, or lodged with management, while allowing the key for day-to-day use be changed in the event it is compromised.

Full Disk Encryption
While encrypted containers solve problems with file-based encryption, they are still not completely secure. Most software is written with no regard for security and may create anonymous temporary files. Many programs, especially graphical ones, have no concept of a working directory and may create these files anywhere on the system - for instance, in a systemwide temporary folder, in the user's home directory, or in an application folder. Even if a user's entire home directory is placed inside the container, there is no guarantee that data files will not be created elsewhere.
Moreover, a modern operating system with virtual memory often operates with a paging file or swapfile - when the system is busy, inactive areas of RAM may be written out to disk. Although some systems allow memory blocks to be locked, programs in general do not use this feature, and the "suspend" feature on laptops will write memory to disk regardless.

Full disk encryption extends the encrypted container to include the entire operating system, including the swapfile and suspend area. The user must enter a passphrase when booting the system, and subsequently has full access to all folders. When the system is off, all data is secure. If the computer or disk is stolen or recycled, an attacker cannot gain access to the data without the key.

Problems with FDE
Although significant - one source suggests that one in three laptops will be stolen - physical theft is not the only risk to computer data. Sensitive data may also be exfiltrated by malware, or exposed by insecure backup practices, or accessed by unauthorized persons when a computer is running but unattended. Full disk encryption is either all on (when the computer is powered down) or all off (when it is running). It thus offers no protection to these latter risks.
These risks are amplified when a computer is dual-use (work/play) - for instance a laptop used both for business, to work on sensitive data, and for personal use. A laptop might be used for entertainment, email, perhaps lent to family members, and all the time the system is running sensitive data is exposed. Also, in many cases when a laptop is in a suspended state - the normal "off" state when the lid is closed or the power button is pressed - the disk encryption key will still be present in memory. The disk may be accessible when the laptop is taken out of suspended state if a login password is not used, or the password may be bypassed by supercooling the RAM and physically removing it from the computer.

Virtual Machines
A virtual machine is analogous to a disk container - instead of a computer filesystem being kept inside a binary file on a host system, a complete virtual computer runs inside a program on a real computer. Since the virtual computer may be running a completely different operating system from the host computer, the virtual machine environment is often combined with a disk container system.
By combining a virtual machine with an encrypted container, it is possible to create a secure virtual computer inside an insecure real one. This offers several advantages. As with FDE, swapfiles, temporary files and configurations are all secure when the virtual machine is not running. As with a container, the sensitive data may be unmounted when not required, and the container may be backed up or copied over an insecure network.
For a dual-use machine, it is feasible to protect the virtual machine against malware by running only trusted or whitelisted software, while using the host operating system (or another virtual machine) for entertainment and personal computing.
While network traffic must pass through the possibly untrusted host computer, it is possible to run a secure VPN inside the client machine.

Testing
There are a large number of different operating systems, virtual machine systems, and encryption schemes, hence the number of possible combinations is huge. I tested only one host operating system (CentOS6 on a 64-bit desktop) and one virtualization program (Oracle VirtualBox).
VirtualBox offers the following features:

• Virtual hard disk with snapshotting and differencing
• Network with NAT, or a local network address
• 32-bit client machines
• Filtered access to USB devices
• Access to directories on the host machine
• Access to physical DVD drives on the host machine
• Access to DVD images on the host machine
• Graphical and command-line management
• Virtual display access to the client machine, with sound output

It is possible to create an encrypted container using e.g. BestCrypt or TrueCrypt, and then create a virtual hard disk inside that for the virtual machine. It is also possible to create a virtual machine in a normal virtual hard disk, and then install a full-disk encryption product in the virtual machine.

Fedora with LUKS
Creating this system was a simple procedure - create a new virtual machine on a new virtual disk, assign a virtual DVD drive to a Fedora ISO install image, and start the VM. When prompted during the Fedora installation process, check "encrypt disk".
When the resulting system is started, during the boot sequence it prompts for an encryption key to be entered using the keyboard, and then boots normally. This is a virtual machine with FDE in an unencrypted container.

XP with BestCrypt
BestCrypt is a container system that I have used for many years. To create a 3Gb container, I use the following commands:

$ bctool new -a idea -s 3000M XPVM
$ bctool format -t ext3   XPVM
$ mkdir XPVMdir
$ bctool mount XPVM XPVMdir

Bctool prompts for a passphrase at most stages. Once the container is available (mounted), I created a new virtual machine in a new virtual disk, as for Fedora, but explicitly selecting the mounted container as the directory in which to place the virtual disk. The container would have to be large enough to contain the VM filesystem and also any snapshots that might be created later.
Installation of Windows XP from an installation ISO image proceeds normally as for Fedora. On starting the VM, there is no passphrase prompt since the container is already mounted on the host operating system. The container must be manually unmounted after use, or a command-line script could be used to combine the operations (mounting/unmounting the container with starting/stopping the VM). This is a normal VM (without FDE) in an encrypted container.

Vista or XP with PGP
Installation of Windows Vista (or XP) is done normally as for Fedora (create a new VM, new virtual disk, boot a virtual DVD Vista installation image). This gives a normal Vista system. Symantec PGP must then be downloaded and installed inside the virtual system, typically with a Web browser. This offers the option to transparently encrypt the entire disk (seen by the VM) on the fly, and assign one or more keys to allow decryption, plus optionally the feature of saving an escrow key on a management server. When the system is rebooted, it will prompt for a passphrase during the boot process. Once the system is running, it is possible to decrypt the disk again on the fly and remove the PGP product.

Centos with PGP
Installation of Centos (32-bit) proceeds normally as for Fedora. Once the system is running, Symantec PGP must be downloaded and installed. On Linux, PGP is a command-line tool "pgpwde". The procedure is something like:

# yum install dkms
# yum localinstall pgpwde-10.3.2-1.15238.1.x86_64.rpm
# yum localinstall pgp-libs-10.3.2-1.15238.1.x86_64.rpm

# pgpwde --license-authorize --license-name "Joe User" \
  --license-number "ABCDE-.....-XYZ"  --license-email "joe@example.com" \
  --license-organization "Example Corp."

# pgpwde --add-user --disk 0 --username root --passphrase something
# pgpwde --add-user --disk 0 --username "Joe User" -a something --passphrase somethingelse
# pgpwde --encrypt --disk 0 --passphrase something --all --safe-mode

Without the "-all" option, not all partitions may be encrypted and the system may be unbootable. After encryption, when booting the user is prompted for the passphrase as for Vista.

Windows 7 with BitLocker
BitLocker is included with professional versions of Windows 7, or in all versions of Windows 8. It is a bit more complicated to configure, since it is primarily intended for use with a TPM chip on newer computers. The VM has no TPM chip, but it is possible to configure BitLocker to run with a USB stick or floppy drive.
Installation of Windows 7 on a VM proceeds in the normal way. Bitlocker may be turned on in Windows Control Panel. But first it must be configured to use the startup key method. See the link below. Run gpedit.msc (Group Policy Editor) to check "BitLocker without a compatible TPM". For this to work, the VM must allow reading of USB devices in the preboot environment. This didn't work for me, even though I enabled USB support in VirtualBox - the USB drive was visible after the VM booted, but not (I presume) in the preboot environment.
Fortunately, there is a second workaround to allow a floppy disk to hold the security key. On the Windows command line, type

manage-bde -on C: -rp -sk A:

and create a floppy disk image on the host operating system:

mkfs.vfat -C "floppy.img" 1440

Then create a virtual floppy drive in VirtualBox and attach it to the disk image. (Ideally, this image would be on a removable media, e.g. a real USB stick on the host system, since when the key is accessed there is no need for a passphrase to be entered. Leaving the floppy image on the host computer would be like leaving the key in the lock after locking your car.) Finally, run BitLocker to encrypt the drive. BitLocker will do this transparently in the background, first splitting the drive into a small unencrypted system partition used for booting, and a large encrypted one for everything else.
When encryption is complete, when the VM is started the system will obtain the key from the virtual floppy and boot normally. If the virtual floppy is not available, the key may be entered by hand using the keyboard - but it does not seem possible to encrypt the drive in the first place using only a manually entered key.

Backups
As discussed earlier, if a backup tool is run inside the virtual machine, it may expose sensitive data in the clear to the network or to the backup process itself (backup media may be accessed by unauthorized agents, or stolen). But the container or virtual disk may be safely backed up by a backup tool on the host system, since it is encrypted.
If a file-based backup tool is used (tar, rsync, etc.), this will be very inefficient, since trivial changes to the filesystem inside the virtual disk will change the signature and modification time on the container file, requiring the entire virtual disk to be copied. Fortunately, if a disk-block based snapshotting tool is used for differential or incremental backup, this problem is solved since only changed blocks are backed up for each snapshot.
Without encryption, if a single byte in a file is changed, then possibly 2 or 3 blocks will be affected (the block containing the changed byte, and other blocks containing the file metadata such as modification time). With encryption, depending on the algorithm, more blocks are affected - the changed data is effectively "smeared out" on the virtual disk. In testing, the single byte changed in a file in a BestCrypt container resulted in about 25 blocks being affected. But this is still vastly better than the thousands or millions of blocks in the entire container that would be required for a file-based backup.

VPNs
A secure VPN may be used to protect data in transit between the virtual machine and a remote trusted machine or network. I tested Cisco AnyConnect and Junos Pulse running on Windows XP on a VM, and Cisco AnyConnect on Vista. The VPN will protect data from sniffing on an open network, and also to some extent from sniffing on the host system if the host is untrusted (might contain malware). It would I think be more secure on a work/play computer to configure both the work and play areas as virtual machines on a clean host. But put it this way - I know that an untrusted host could easily monitor VM traffic if a VPN is not used.

Data in transit may also be protected by end-to-end encryption using e.g. SSH or SSL using controlled keys. Note that the SSL encryption built in to Web browsers may no longer be considered secure due to the dilution of trust in chained certificates (there is no guarantee that the server certificate was issued by the correct authority).

Conclusion

Putting all this together, the following is my recommendation for a laptop used to process sensitive data:

• Laptop with host operating system
• Virtual machine system (virtualizer)
• Backup or snapshotting system capable of performing incremental or differential disk-block based backups of virtual disks
• Guest operating system with:
  • Full disk encryption with key management
  • Secure VPN
  • Programs required to actually work with the data

The guest operating system should should be snapshotted and stopped when unattended, or actually shut down. No risky activity (reading email, browsing websites) should be performed inside the guest operating system. If possible, no vulnerable or promiscous software should be installed - no browser plugins (Flash, Java, Adobe Reader), Bittorrent, Dropbox etc. Sharing of folders and networks between the host and guest systems should be kept to a minimum.

Risks Revisited
How the system described above should mitigate the perceived threats:

• Physical loss or theft of a computer or disk containing sensitive data.
  • The virtual disk is offline and encrypted when not in use; the key is kept separate from the computer
• Access to data by a third party when a computer is sold or recycled.
  • As above
• Copying of sensitive data in transit over an open network (e.g. open WiFi at an airport or hotel).
  • Data in transit is protected by a secure VPN
• Exfiltration of data from a computer infected with malware, such as keyloggers or backdoors.
  • The virtual machine hosting the data is kept clean and free from vulnerable software and user behaviour. The risk is reduced, not zero.
• Access to data by a stranger while a computer is unattended.
  • The virtual machine is shut down when not in use. The speed with which a VM may be snapshotted and restored means that this is not as annoying to the user as shutting down a real computer. Also, for a dual-use computer, there may be long periods when the virtual disk is not required and the computer is used for other activity.
• Access to sensitive data by persons who have the owner's permission to use the computer for an unrelated purpose.
  • As above
• Exfiltration of sensitive data from a computer due to the normal operation of backup or online synchronization processes, which may copy the data over an insecure channel or to insecure media.
  • No backup processes run inside the virtual machine. The encrypted virtual disk is snapshotted and backed up from the host machine.
• Inability to access data due to the loss of encryption keys.
  • Keys must be kept in escrow.
• Loss of data due to hardware failure of storage media.
  • Backup copies of virtual disks may be restored to a virtual machine on new media, or on another computer.
• Loss of data due to human error (accidental erasure)
  • As above
• Loss of access to data due to failure of the hardware used to read the media
  • As above. A virtual machine should be less sensitive to the need for particular hardware and device drivers than a regular operating system image.
• Loss of access to data due to obsolescence of the computer system used to read the media.
  • Full source code of the virtual machine and encryption software may be backed up along with the virtual disks. But after fifty years, maybe the data should be erased or declassified and published.
• Risk of "bricking" a system when installing FDE, e.g. from latent disk errors or operator error
  • Virtual disk images may be backed up before FDE is installed - this is trivial compared to imaging a complete computer before installing FDE. But there is likely no need to retrofit FDE to an existing installation - a new VM may be created and FDE installed on that at little risk. I bricked a CentOS VM trying to install PGP, and didn't lose anything other than a few minutes of time to create a new one.

Links

• 5 best VM applications (Jason Fitzpatrick @ lifehacker, 12/19/10)
• Comparison of platform virtualization software (Wikipedia)
• VirtualBox: Guest OSes
• Fedora VirtualBox USB working (kernelhardware.org)
• Install VirtualBox on CentOS 6
• Installing and using VirtualBox on CentOS (wiki.centos.org)

• Comparison of disk encryption software (Wikipedia)
• LUKS (Wikipedia)
• Symantec Drive Encryption (pgpwde)
• How to Encrypt using Windows BitLocker (it.ucsf.edu)
• Using BitLocker under Virtual PC / Virtual Server (Ben Armstrong)
• Jetico (BestCrypt)

• Block Based Backup Technology (Idera whitepaper)
• Areca Backup