Strange handling of encryption keys in case of encrypted media vs. encrypted VM.

[ams_tschoening]

I recently tested a bit with encrypted media and got some questions about encryption key handling of VirtualBox for which I couldn't find answers in the official docs. So please let me describe what I've did and the arising questions here as well, maybe any of you can answer those.

I have created a new medium and encrypted it according the docs[1] WITHOUT attaching it to a VM first. This succeeded and made me wonder where the encryption keys got saved? According to some blog posts and because of tests I made before with encryption on VM level, those should be saved in the XML config of a VM, but in my case I didn't have a VM the media was attached to. I had a look in the global configuration file of the user running the VBoxManage command as well and didn't find any keys.

So where should the keys be saved if only a new medium was created and encrypted, e.g. using VBoxManage, WITHOUT attaching that medium to a VM before encryption?

Afterwards I attached the newly created, encrypted media to some test VM and at some point recognized keys in the XML config of the test VM. Did some testing and stuff and removed the medium from the test VM again to attach it to another VM. But looking at the config of the first test VM, the keys of the re-attached medium is still present there, not in the VM where the medium is currently attached to. Additionally, it is really ONLY attached to the new VM, not the former test VM anymore.

Shouldn't the keys now be part of the one and only VM the medium is attached to? I'm supposed to backup the keys for all media, but how should I do that reliably if I can't be sure where the keys are actually stored? In my case the first VM was for test purposes, the second for production. What happens if I delete the test VM now, still containing the keys of my encrypted medium, even if it's not attached anymore?

As I'm seeking for as much details about the intended behaviour as possible, I've posted my questions at superuser[2] and created a ticket[3] as well. Can't post the URLs currently, might edit them later in if possible.

[mpack]

The VM which registers media does not have to be the same VM which uses it. VirtualBox creates a virtual global media register when the background service starts, the union of all registered VMs media registries, so it doesn't really matter which VM registers what.

As to the encryption keys, I would never use that feature, but I'd think the same applies.

I don't know where your keys were stored when the media wasn't registered, I'd have thought that if you did that then the drive contents should be unrecoverable: plus I thought that the key applied to whole VMs, not to individual media files - which again argues that the public key ought to be found in the .vbox file of one VM.

BTW., I assume you're aware that if you encrypt a drive and you lose the associated .vbox file then the drive is toast with no possibility of recovering the data.

[scottgus1]

I used this command to make an unattached vdi disk:

Code: Select all

VBoxManage createmedium disk -filename "P:\testenc.vdi" -size 100

Then I encrypted it with this command:

Code: Select all

VBoxManage encryptmedium P:\testenc.vdi --newpassword - --cipher "AES-XTS256-PLAIN64" --newpasswordid "testenc"

if I run the above commands while there is no main Virtualbox window open, and I wait until VBoxSVC.exe closes, then I open the main Virtualbox window, the Media Manager does not list the new disk.

If I ran the above commands with the main Virtualbox window open, the Virtualbox Media Manager reports the new disk in the list as encrypted. When I close the main Virtualbox window before attaching the new disk to a guest, and wait for the VBoxSVC.exe service to close, then re-open the main Virtualbox window, the newly made disk is no longer in the Media Manager.

When I re-open the main Virtualbox window and attach the encrypted disk to an existing guest the Media Manager reports the new disk but shows that it is not encrypted. When I start the guest the command-line-encrypted disk has been attached to, the guest does not stop and ask for the password I gave, and it is able to see and format the new disk and save files to it.

When I shut down the above guest and remove the new disk from the guest, I close the main Virtualbox window and wait for VBoxSVC.exe to close. I then run the encrypt command on the disk again. The command completes. I then open the main Virtualbox window. The Media Manager does not list the re-encrypted disk. I then add the re-encrypted disk to the guest. Media manager reports the disk as not encrypted. I start the guest successfully without being asked for a password. The new disk is present in the guest OS but needs to be re-formatted to use.

However, if I run the commands while the main Virtualbox window is open and attach the new encrypted disk to a guest before I close the main Virtualbox window, the guest does ask for the password and operates with the encrypted disk as normal.

From these experiments I deduce that Vboxmanage-command-line-made disks aren't permanently a part of Virtualbox until they are attached to a guest. And if the main Virtualbox window is not open when the commands are run, disks encrypted while not attached to a guest are "encrypted", but the key is not written down in any Virtualbox data files so that Virtualbox knows that the command-line-generated disk is encrypted and to ask for a password when it is used again. (<- this sounds like data loss time. Don't encrypt an un-attached disk from the command line unless you have a good backup in place and the main Virtualbox window is open. And don't close the main window until you attach the disk to a guest.

[mpack]

I'm not sure about what your last paragraph there is saying Scott, but from the paragraphs before it, it sounds like you're saying that VirtualBox silently ignores the attempt to encrypt disks which are not registered? That would be a minor bug, but it would make sense.

[scottgus1]

Virtualbox does encrypt the disk (or at least jumble the data), but it doesn't write down the DEK anywhere, so the disk can't be decrypted to use. ie foobar....

Not encrypting unregistered disks would be good. Encrypting and losing the DEK, not so much.

[Martin]

Vbox doesn't seem to have a concept (to store the keys) of encrypted media not attached to a VM.
If you don't attach the disk to a VM the "knowledge" of the encryption is lost and the disk is left just as a container of random date, therefore has to be reformated before being used again.

[ams_tschoening]

Already thought the same, but they should document such things properly. Not only about unattached images, but that DEKs are not moved around VMs as well. While I do understand the reasoning behind that, all known configs are assumed as one global pool, so no need to know where the DEKs are actually stored in a file, it makes backups and tests MUCH harder. If one consider such things implementation details which are handled on attaching and removing disks from VMs, one could easily loose DEKs attached to unexpected VMs.

So this feature really looks broken and too dangerous to use currently. that's sad, because encrypting in the VB host was a lot faster than using cryptsetup in the guest according to some benchmarks with my VMs.

Thanks for your additional tests, Scott!

[Martin]

The cureent feature probably got implemented for some commercial customers who don't need to handle disk files seperately from the VMs.
The manual is pretty clear about the pitfalls and limitations:
The DEK is stored encrypted in the medium properties and is decrypted during VM startup by entering a password which was chosen when the image was encrypted.
Since the DEK is stored as part of the VM configuration file, it is important that it is kept safe. Losing the DEK means that the data stored in the disk images is lost irrecoverably. Having complete and up to date backups of all data related to the VM is the responsibility of the user.

[scottgus1]

One thing that wasn't mentioned in the manual, if I read properly, is that the DEK can be lost if the disk is removed from the guest. Forum users discovered that one, to some folks' dismay.

I suspect the "encrypt-an-un-registered disk-lose-the-DEK" is just an oversight. Bugtracker time...

[ams_tschoening]

One thing that wasn't mentioned in the manual, if I read properly, is that the DEK can be lost if the disk is removed from the guest.

It's not even lost until the disk is removed from media manager, because it's kept in the last attached VM. But that's a major pitfall as well, because moving images between VMs and then deleting VMs entirely doesn't seem that uncommon. And VirtualBox doesn't seem to warn about loosing any DEKs still associated with the VM because of implementation details.

[scottgus1]

Further testing has revealed this method to hose a disk:

1. Release a good unencrypted disk from a test guest (make a copy for a backup). (a brand-new disk won't have anything in it, so the data loss below really won't affect a new disk) Unregister the disk from the Media Manager so it does not show in the list. Close all Virtualbox windows. Ensure that the VboxSVC.exe process has closed.

2. Run the "VBoxManage encryptmedium" command line on the good disk file.

3. The running of the command will launch a new VBoxSVC.exe to support the command. When the command completes, the associated VBoxSVC.exe will close in a few seconds. If you can get the main Virtualbox window open before the VBoxSVC.exe from the command line closes, and attach the disk to a guest before shutting the main window and losing the VBoxSVC.exe, the newly-encrypted disk will run properly.

4. If you cannot get the main Virtualbox window open before the command's associated VboxSVC.exe closes, or you get the main window open and then close it again before attaching the newly encrypted disk, and the associated VBoxSVC.exe closes, then the main Virtualbox window will not know the disk was encrypted when you do try to use it in the future. The DEK for that disk will be lost when that VBoxSVC.exe closes, and the disk's internal data is scrambled and unusable.

Bugtracker: https://www.virtualbox.org/ticket/16784

My suggestion in the Bugtracker post is to not encrypt unregistered disks: require registering the disk with a guest before encryption, so the DEK has a .vbox file waiting for it.

[socratis]

Scott, I replied to you in the ticket, but I'll copy/paste the reply here, since this is where this discussion should be taking place, not in the ticket. A lot more people are watching/learning from/contributing to this, myself included...

You don't have to have the DEK key anywhere written. Think of a password-protected ZIP. Now, if you have an unregistered VDI, like the one you created in the command line (CLI) above, you can successfully encrypt it from the CLI. You can also successfully decrypt it from the CLI as well. See ch. 9.31.4 Decrypting encrypted images (I'm quoting the whole chapter, mind you ):

In some circumstances it might be required to decrypt previously encrypted images. This can be done in the GUI for a complete VM or using VBoxManage with the following command:

• VBoxManage encryptmedium "uuid|filename" --oldpassword "file|-"

The only required parameter is the password the image was encrypted with. The options are the same as for encrypting images.

[mpack]

You don't have to have the DEK key anywhere written. Think of a password-protected ZIP.

Where did that come from? Has there been a change?

A password protected zip encrypts the zip directly with the entered password. The password must still be stored - in your head.

Unless things have changed recently, that is not how VirtualBox encryption works. When you encrypt a VM the private key is assigned by the OS, this is used to encrypt the drive. The public key component is stored in your .vbox file, encrypted using a simpler algorithm and your password. You absolutely DO need to keep the real DEKs stored in a VBox file, because you can't decrypt the drive using only your password.

I did suggest to Michal that this heavy duty public key encryption was more than is needed for a VirtualBox VM, and that zip style simple encryption should be enough. It would be nice to think I influenced a design change, though I doubt it.

[ams_tschoening]

mpack is correct, the docs are very clear about that and one can easily test the behaviour of VirtualBox by simply looking at the configuration files. The password itself is NOT enough, a VM config is needed to store the DEK and that needs to be backed up as well. An encrypted image only can not be decrypted without the DEK just by entering the password itself, I've testet that by downloading an image only from my production VirtualBox host and adding it to my local VirtualBox instances. The data is not accessible to VirtualBox, it doesn't even know that the image is encrypted. If you look at the image using some HEX editor, there doesn't seem to be any indication of encryption.

VirtualBox uses the AES algorithm in XTS mode and supports 128 or 256 bit data encryption keys (DEK). The DEK is stored encrypted in the medium properties and is decrypted during VM startup by entering a password which was chosen when the image was encrypted.

Since the DEK is stored as part of the VM configuration file, it is important that it is kept safe. Losing the DEK means that the data stored in the disk images is lost irrecoverably. Having complete and up to date backups of all data related to the VM is the responsibility of the user.

Chapter "9.31. Encryption of disk images" from the official docs, I'm still not allowed to provide links.

Code: Select all

<HardDisk uuid="{e906f17a-e146-4266-8938-ef0107948866}" location="VT Platte 1.vdi" format="VDI" type="Normal">
	<Property name="CRYPT/KeyId" value="..." />
	<Property name="CRYPT/KeyStore" value="..." />
</HardDisk>

[socratis]

Where did that come from? Has there been a change?

The user manual. I don't think there was a recent change in the documentation. I'll check the trunk.

I tried the following:

• Created empty "test.vdi" from the command line. VDI is not registered. I encrypted the VDI from the command line. VDI was empty, so I'm not sure that the encryption of zeroes/nothingness does anything in reality:

  Code: Select all

  $ VBoxManage encryptmedium /Users/socratis/test.vdi --newpassword - --cipher "AES-XTS256-PLAIN64" --newpasswordid "testenc"
  Enter new password:
  0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
  $

• Attached to Win7. Formatted (NTFS), copied a couple of files.
• Detach from Win7. VDI shows in the Media Manager as NotAttached, NotEncrypted. Quit VirtualBox.
• Re-launch VirtualBox. Attached test.vdi to another, Win7-64. Files read OK, no password was asked for.
• Detach test.vdi from Win7-64. Removed from the Media Manager. Closed VirtualBox. I encrypted the VDI from the command line a second time.

  Code: Select all

  $ VBoxManage encryptmedium /Users/socratis/test.vdi --newpassword - --cipher "AES-XTS256-PLAIN64" --newpasswordid "testenc"
  Enter new password:
  0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
  $

• Attached to Win7. VDI shows in the Media Manager as Attached, NotEncrypted. Disk shows as uninitialized!
• Shut down Win7. Detach test.vdi from Win7. Removed from the Media Manager. Closed VirtualBox.
• Copied VDI to another host. Attached to WinXP. Disk shows as uninitialized!
• Closed VirtualBox. I decrypted the VDI from the command line.

  Code: Select all

  $ VBoxManage encryptmedium /Users/socratis/test.vdi --oldpassword -
  Enter old password:
  0%...
  Progress state: VBOX_E_INVALID_OBJECT_STATE
  VBoxManage: error: Failed to encrypt hard disk
  VBoxManage: error: The image is not configured for encryption
  VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component MediumWrap, interface IMedium
  VBoxManage: error: Context: "RTEXITCODE handleEncryptMedium(HandlerArg *)" at line 1853 of file VBoxManageDisk.cpp