How to Attach Encrypted vdi to VM in VBox 5.0

[michaln]

While "strong disk encryption" may not rhyme with "common sense" too well, it does rhyme with "customer requirement". So there's that.

I totally understand your concerns, and I wish more people (especially IT managers) understood that encrypting data is not like putting a lock on a door -- there's no locksmith you can call when you lock yourself out.

[noteirak]

I think there should be clear warning just before encrypting the image that the real key is not the password, but saved in the config file of the VM. To make it even more sure, I would add a checkbox with a message along the lines of "Yes, I understand I must keep the .vbox safe".
The feature itself is counter intuitive since virtually all softwares using encryption only require the password for the data to be recovered. People are not used to this type of behaviour.
I think having an extra warning on a feature with such data loss risk is acceptable. If they still don't read the user manual by that point, then that's it...

[scottgus1]

I've been following this conversation and I do agree that since losing the vbox file causes total data loss there should be a really prominent warning of such danger and a "yes-I-read-the-warning" checkbox before enabling encryption.

But I have a thought. I have a couple TrueCrypt volumes on my PC. I can move the volume file to another PC and mount it with just the password. So the encryption key that compares with the password apparently is stored in the volume file itself. (I believe one can choose to have a separate key file if one wants.)

Is there reserved space in the VDI specification that could be used to store the DEK key that is now put in the vbox file? Of course we couldn't do that - the developers would have to re-work the program to do it. But could they put the DEK in the vdi?

Edit- scratch the above, the manual says the intent is:

It does not depend on a specific image format to be used

(Section 9.31)

The warning is a really good idea.

[loukingjr]

Warnings are only worth anything if a user heeds them. There are multitudes of posts here and elsewhere on the web where warnings were ignored and users still blamed anyone but themselves.

Just saying.

[noteirak]

I agree. But such a critical feature should have a JITW (just-in-time-warning). Documentation alone is dangerous, especially since other softwares don't proceed that way.
The JITW is also a way to give responsability to the user - there is no way he/she could have encrypted the disk without accepting the warning. Blindly accepting it without reading is the user problem.

It's obviously always a very grey line of where the devs' responsability ends and the end-user's starts. In this case, given how you can loose ALL your data, an extra warning should be created.

[loukingjr]

Perhaps just a warning then either by mouseover or popup that warns encryption increases the possibility of total data loss. See manual…

[ChipMcK]

DOS 2.01 days

Code: Select all

Erase *.*
Are you sure? [Y/N]
y

Cut to audio track of user screaming at the computer.

[xjames7tcr]

Thanks to this retarded shit i lost all my encrypted data on my .VDI ! i didnt know i had to save the .vbox config file! thank you all team ! you the best!

[socratis]

i didnt know i had to save the .vbox config file!

@xjames7tcr

1. You didn't even read the documentation. Assuming something can be dangerous, sometimes catastrophic.
2. You didn't even experiment with a test VM to see whether your understanding of the feature is correct or not.
3. But you can always restore from backup, right? You did take a backup before that dangerous operation, right?

[mpack]

Thanks to this retarded shit

VirtualBox is a tool. It can't be retarded because it never had a brain to begin with. You are supposed to be the one with the brain.

On that last score I must say that I have my doubts, considering the long series of compounded mistakes you have to make in order to reach the state of: coming here to complain about not being protected from your own mistakes.

[loukingjr]

Thanks to this retarded shit i lost all my encrypted data on my .VDI ! i didnt know i had to save the .vbox config file! thank you all team ! you the best!

"It's a poor workman that blames his tools."

[hitone]

The data in the disk images is encrypted with a separate DEK (Data Encryption Key) which is completely random and not based on the UUID or the password. The DEK is encrypted/decrypted using the password when the data in the image is accessed. The DEK is stored in the medium properties in the .vbox settings which needs to be kept safe in order to decrypt the content in the image as explained here: https://www.virtualbox.org/manual/ch09. ... encryption.
If you didn't preserve at least the CRYPT/KeyStore data somewhere your data is lost irrecoverably because the DEK is the only existing key to decrypt the data.

Just want to weigh in here since I just had an annoying experience with MacOSX and their apfs/high sierra update, and I am now dealing with this VB disk image encryption issue. I'd like to point out a few things:

1. The documentation seems a bit ambiguous. Although the first few lines of section 9.31 state that the VB DEK is stored in the configuration file, section 9.31.4. "Decrypting encrypted images" states:

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.

The last sentence, besides saying that the "encryptmedium" option should be used to decrypt, leads me to believe that the password is the only requirement to decrypt an image. I suspect that the image to be decrypted must be registered first, but I wonder how VBoxManage knows which configuration file to pull the DEK from.

2. I must admit that I am guilty of not reading the documentation earlier - I noticed the new encryption option and checked the box, set a password and pat myself on the back thinking I just added another layer of security to my precious files. Things worked fine until, amazingly enough, I wanted to make a backup. My backup routine in the past was simply copying the *.vdi disk image files to an external (encrypted) drive. I'd then test out the copy by detaching my originals, attaching the copies, and starting up the VM. And then, to my embarrassment, the original configuration file - and DEK - was overwritten. The newly attached disk image was not detected as having previously been encrypted, and I ran into the same issue as the OP where there was no bootable disk/OS found. So, it seemed that I had a redundant and perfectly unusable set of disk image copies. I was completely disgusted with my own ignorance after finding this thread. Luckily for me, I did end up finding the original DEK, in a strange place...the VM log files.

3. For anyone that has run into this issue, and has lost the original .vbox configuration file, you may be able to find your DEK in one of the *vbox.log.* files in the Logs directory of your VM. You will need to reformat the string in the log file to match the configuration file format, but this is easily performed in a text editor.

So, besides costing a few hours and hairs on my head, this was a very good lesson on knowing what needs to be saved with your encrypted disk image.

I would like to second mpack's suggestion regarding the disk image and DEK - keeping these two bound together is a great idea. At the very least, a .key file saved in the same directory as the .vdi disk image would be awesome. And, even though having the DEK in the log files saved my bacon, I'd suggest masking or removing it at some point (after incorporating the DEK into the disk image, of course). Lastly, attaching a previously encrypted drive should generate some warning ("Hey, Mr. VB User, this disk seems unbootable - is it encrypted? If it is, you will need to update the configuration file with the DEK..." - or something condescending, perhaps a reminder that this is free software. Just kidding.) Sorry for the long post!

[mpack]

The last sentence, besides saying that the "encryptmedium" option should be used to decrypt, leads me to believe that the password is the only requirement to decrypt an image.

Well, that obviously isn't what the quoted text says. The text only says that the relevant VBoxManage command has one additional parameter. Obviously there is an almost infinite number of implied assumptions that must be valid for this command to work. E.g. VBoxManage has to be installed, the disk has to be present, and encrypted... etc.

I suspect that the image to be decrypted must be registered first, but I wonder how VBoxManage knows which configuration file to pull the DEK from.

I imagine it does it the same way as for all other disk commands: the background VBox service builds a compound media registry with local media data taken from all registered VMs.

And, even though having the DEK in the log files saved my bacon, I'd suggest masking or removing it at some point.

I assume it already is masked. The DEK stored in the .vbox file is encrypted using your password and, unless the devs made a really dumb mistake, the DEK in the log is the same. It could be pointless to obscure it further in the log when the .vbox file is right there beside it.

I also don't see what would be achieved by adding another config file to store the DEK. (a) I don't see why this is better than storing it in the .vbox file, because (b) people wouldn't back up that file either.

p.s. My suggestion was not to store the DEK in the VDI, that would again be pointless, because the effect would be that you can always decrypt any copy of the VDI knowing only the password. And if that's the effect you want (and it would be what I want) then I'd suggest just encrypting the VDI directly with the user password, since the intermediate steps add nothing to the security of the file - so why store the DEK at all?

[hitone]

Well, that obviously isn't what the quoted text says. The text only says that the relevant VBoxManage command has one additional parameter. Obviously there is an almost infinite number of implied assumptions that must be valid for this command to work. E.g. VBoxManage has to be installed, the disk has to be present, and encrypted... etc.

My mistake. I meant that the second to last line uses the "encryptmedium" option, when "decryptmedium" would be more likely/intuitive (maybe that's a typo). This is what was documented for decrypting disk images:

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

The last line was this:

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

The above states that the only required parameter is the password. To me, that means all you need is the password to decrypt. I guess we will agree to disagree on that interpretation. My command of the English language is quite suspect.

p.s. My suggestion was not to store the DEK in the VDI, that would again be pointless, because the effect would be that you can always decrypt any copy of the VDI knowing only the password. And if that's the effect you want (and it would be what I want) then I'd suggest just encrypting the VDI directly with the user password, since the intermediate steps add nothing to the security of the file - so why store the DEK at all?

Yes, decrypting the .vdi knowing only the password is the effect I want. I only saw storing the DEK in the same directory or incorporating it into the .vdi as a quick means of achieving that (storing the DEK with the .vdi does make it somewhat more likely that it would be backed up along with the .vdi - for those like myself who have become used to only backing up the .vdi). Thank you for responding.

[OnionRoger]

I know the documentation probably explains it, but until now my experience with VirtualBox had been that it was very easy and intuitive to use, so I trusted the software to be user friendly. I think if the .vbox file has a key that is required to decrypt the volume on top of the password the creation process should prompt the user with the key and ask them to copy that key in a safe location so they can use it later to recover the data, otherwise, if they only provide the password to encrypt it that should always be enough to decrypt it. That's in my experience how it works most of the time, except some unfortunate exceptions (like VirtualBox). Thankfully I had a backup of my data elsewhere, but still not being able to recover a lost VM when I still have the disk and the password is annoying.