Handling of encryption of individual virtual disks

[dry]

After chatting with socratis on irc and seeing this thread (sorry not allowed to put a u r l as this is my first post .. ) named "Strange handling of encryption keys in case of encrypted media vs. encrypted VM."

I'm not sure what was the conclusion on that discussion, but I think socratis was hoping you can have individual images encrypted outside of the machine, by using VBoxManage.
Yes you can, and I'm using it. Today after reading discussion, I got also in doubt that I can move my encrypted disk to another PC, because, apparently, they would be stored in some secret VBox global registry/file
(dunno where to find it or where it should be ..), and, if you remove the disk image in question from virtual manager, it will be a goner - all encryption/keys lost.

This is not true for those images/disks you created with VBoxManage encryptmedium xxxx --cipher AES-XTS256-PLAIN64 --newpassword xxxxx --newpaswordid xxx. I use new password and key.
You encrypt, attach, and use the disk. Note that, in my original machine config there is no disk encryption enabled, it is enabled by using this externally encrypting command above.
If you examine the machine's .vbox file, you will see under the HardDisk properties the KeyId and KeyStore. The key information is stored on the disk image file, not some secret VBox media manager.
Copy these XML properties.

Now shutdown machine & remove the disk from it and from the virtual disk manager - but keep the file obviously. The disk now is forgotten. Examine the *.vbox xml property files now. You will see that all CRYPT info of the disk is gone, and , you would get worried you lost all info. You attached back the disk, and examine *vbox again to see that there is _no_ CRYPT props again : you get worried.
You start the vm, it runs, but when you try to access (assuming previously formatted / used but encrypted disk) that file, you cannot - cannot mount, use.. Because it was in fact encrypted, and Vbox does not decrypt it now. You panic?

No, as in this case, all info is saved in that file - which is not secure as someone may decode it, but that's another issue - so you can just restore those xml properties (copied above) to the disk. After you do this, voila : you back un-encrypting it. (and I have, in fact, atm 2 such images with 2 different passwords/keys).

Now after chat with socratis, i was worried it's still local to my settings and that key is hidden in fact somewhere else, so I tested my copying encrypted disk to another machine. And again, i just edit the *.vbox to set the CRYPT props, and it gets decrypted fine and I use all data.

Now, if you did not copy the XML properties for CRYPT, and you removed the disk that is inconvenient. As now VBoxManage will show that encryption is disabled, and I don't know how else with VBox tools, you would get encryption info.

You might ( I haven't tried yet) however get the required info using vbox disk image encryption cracker tool here ...

EDITED: I wrote bollocks about the cracker tool - it doesn't look into disk image, and I don't know if that info is stored in any of the vbox disk images (it makes more sense if it doesnt).

[dry]

I saw this thread: viewtopic.php?f=36&t=68733&p=327290&hil ... ty#p327290

the tool ideally to get these properties is VboxManage mediumproperty ... . BUT , it "pretends" or works only with VBox virtual media manager, thus , by the looks , it ignores that the actual info we would want
(the CRYPT/xxxxx properties) is on the files themselves.

On the first thought, it is a pity because, as we saw, the keys info is in the file anyway.

[fth0]

As far as I know, the following applies:

Q: Where is the key material stored?
A: The KeyId and the KeyStore are only stored in the VM configuration file (*.vbox) and not in the disk image (*.vdi, *.vmdk, ...). Additionally, they are kept in RAM inside the VBoxSVC process, which runs in the background while one of the frontends is running (VirtualBox GUI, VBoxManage, ...), and terminates several seconds after the last frontend is terminated.

Q: Why is this relatively secure?
A: The KeyStore contains, amongst other things, the encrypted DEK (Data Encryption Key). If you use a strong password, you could even make this encrypted DEK public. For example, the popular TrueCrypt/VeraCrypt software stores this information inside the header of its disk images at a well-known position. The security lies in the PBKDF2 algorithm, which is used to process your password in multiple rounds, so that a password cracker is slowed down enough when trying brute force attacks.

[socratis]

You might ( I haven't tried yet) however get the required info using vbox disk image encryption cracker tool here : google for "VirtualBox disk image encryption password cracker".

In a word? Crapware. They're trying the brute-force attack, not taking advantage of a flaw in the encryption algorithm. If you have a strong password, good luck using these script-kiddie tools. You're going to need a server farm to break that, even if.

Here's what I tried... Create a new VDI and encrypt it:

• 
  VBoxManage createmedium disk --filename EncTest.vdi --size 20480 --format VDI --variant Standard
  VBoxManage encryptmedium EncTest.vdi --newpassword - --cipher AES-XTS128-PLAIN64 --newpasswordid EncyptedVDI

1st test

• Create a new VM in VirtualBox, don't assign a hard drive. Obviously there's no <MediaRegistry> section. VM Settings » Storage » Add Hard Disk » Choose existing disk » Add » navigate and choose "EncTest.vdi" from before. The .vbox file looks like:

  <MediaRegistry>
    <HardDisks>
      <HardDisk uuid="{31365364-4bdd-49c7-abaf-caa40b55ad85}" location="/Users/socratis/EncTest.vdi" format="VDI" type="Normal"/>
    </HardDisks>
  </MediaRegistry>

  No mention of CRYPTO anything. Starting the VM results in no password being asked.

2nd test

• Create a new VM in VirtualBox, Use an existing virtual hard disk file. Navigate and choose "EncTest.vdi" from before. The .vbox file looks like:

  <MediaRegistry>
    <HardDisks>
      <HardDisk uuid="{c8fac525-03fa-475c-9d6f-d526ebe7b788}" location="/Users/socratis/EncTest.vdi" format="VDI" type="Normal">
        <Property name="CRYPT/KeyId" value="EncyptedVDI"/>
        <Property name="CRYPT/KeyStore" value="U0NORQABQUVTLVhUUzEyOC1QTEFJTjY0AAAAAAAAAAAAAAAAAABQQktERjItU0hB
  MjU2AAAAAAAAAAAAAAAAAAAAAAAAACAAAAAhQ/PeYQDrgoza6n9w2ZntHmFlH7d+
  mbRPiE6coeJzUSAAAABJu9xhzb/T+YAFiG0ty5ACW7ygccusOA53rbvmNwfjzSBO
  AADdICpk7Q/kkU8f+8U5v2OaEwcZNIP70a825zCPNgJSc6BoBgAgAAAAXZ7Fd1yT
  aMBEd+9YWJP0jQGtpvf2r5sAR5IawZOmKpkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  AAAAAAAAAAAAAA=="/>
      </HardDisk>
    </HardDisks>
  </MediaRegistry>

  Password is asked during VM startup.

[dry]

You might ( I haven't tried yet) however get the required info using vbox disk image encryption cracker tool here : google for "VirtualBox disk image encryption password cracker".

In a word? Crapware. They're trying the brute-force attack, not taking advantage of a flaw in the encryption algorithm. If you have a strong password, good luck using these script-kiddie tools. You're going to need a server farm to break that, even if.

That wasn't the point : brute or not. ( And yes it is trivial, but good luck actually trying to find flaw in that encryption algorithm - you actually more likely to crack the likely limited, by social experiment, password.)

So anyway, the point of referring to that tool, is to highlight how one could recover the needed fields / crypt properties in that file, like the encrypted key. Which you then just unlock with your own known password.

[fth0]

@socratis:
You can check if the KeyStore is stored in the VDI file by searching a hexdump of your VDI file for 'SCNE', 'AES-XTS128-PLAIN64' or 'PBKDF2'. If the KeyStore is not in your VDI file (like in my own experiments), it probably survived in the VBoxSVC service during your tests, and the method in your 1st test simply didn't get it from there, while the method in the 2nd test got it from there. (You already know about the shortcomings of this technique from your old 'Strange handling ...' discussion two years ago.)

So anyway, the point of referring to that tool, is to highlight how one could recover the needed fields / crypt properties in that file, like the encrypted key. Which you then just unlock with your own known password.

I don't understand what you really mean by that, or alternatively it's wrong, because:
The 'cracking' tool simply takes the (publicly readable, BASE64 encoded) KeyStore from the vbox file (not from the VDI file), and uses a given wordlist to try as possible passwords.

[socratis]

You can check if the KeyStore is stored in the VDI file by searching a hexdump of your VDI file for 'SCNE', 'AES-XTS128-PLAIN64' or 'PBKDF2'.

This is what I got:

$ strings EncTest.vdi
<<< Oracle VM VirtualBox Disk Image >>>
#$yJ

And I looked at it with a couple of hex editors (0xED, Hex Fiend) and there was nothing there except the header part, and a bunch of 0x00 and 0xFF. I'm not sure if the VDI specification calls for a place where that would be stored actually, see: All about VDIs.

[fth0]

And I looked at it with a couple of hex editors (0xED, Hex Fiend) and there was nothing there except the header part, and a bunch of 0x00 and 0xFF.

That's exactly what I've been writing the whole time: The KeyStore is never stored in the VDI files. It is only ever stored in the vbox file (the recipe, as you like to call it). (I just couldn't be absolutely sure because I'm still running VirtualBox 5.2.x on all of my hosts.)

If you have any questions about the contents of the KeyStore and how the user password and the KeyStore work together from a security perspective, I'll gladly answer as best as I can.

[socratis]

That's exactly what I've been writing the whole time: The KeyStore is never stored in the VDI files.

Yeah, I said that too:

I'm not sure if the VDI specification calls for a place where that would be stored

The VDI that's atatched to a VM, yes, it stores the keys in the VBOX file. My question/exercise wass what exactly happens if you are encrypting a standalone VDI. Couldn't figure it out easily.

But then again, as I mentioned, I never use encryption, so it's more of a mental exercise...

[fth0]

My question/exercise wass what exactly happens if you are encrypting a standalone VDI. Couldn't figure it out easily.

Reading your statement, I cannot judge, if you still have an open question or not (you only made it clear that you don't need an answer ).

If the KeyStore is not in your VDI file (like in my own experiments), it probably survived in the VBoxSVC service during your tests, and the method in your 1st test simply didn't get it from there, while the method in the 2nd test got it from there. (You already know about the shortcomings of this technique from your old 'Strange handling ...' discussion two years ago.)

Regarding your tests, did I guess correctly or not?

[dry]

I don't understand what you really mean by that, or alternatively it's wrong, because:
The 'cracking' tool simply takes the (publicly readable, BASE64 encoded) KeyStore from the vbox file (not from the VDI file), and uses a given wordlist to try as possible passwords.

Hi,
Ok, so I got it wrong then (only glanced at that tool ..): I saw it does a hexdump/ byte map, and assumed (i know , it's a b*h) it gets the encoded key/ protected from the vdi file.

Well too bad if you only got file and lost keystore, but it's good if your file is stolen then.

I'm happy at least I could move my encrypted drive to another machine.

[dry]

...My question/exercise wass what exactly happens if you are encrypting a standalone VDI. Couldn't figure it out easily.

That's the only thing I tested really. If I encrypt it externally, the crypt info gets into that xml vbox file , which you can then extract & save.
Then I could copy the drive to another machine, and re-insert that (text) into xml and get the drive decrypted on another machine. So at least, I got way to move it / back it up.

The hacktool, as I wrote, I never used / tested myself.

[jk08]

I have a vdi file and password (AES-XTS128-PLAIN64), but no vbox file. CRYPT/KeyStore is lost. Can I decrypt a vdi file?

[scottgus1]

CRYPT/KeyStore is lost. Can I decrypt a vdi file?

If the keystore data is truly lost, then no, you cannot decrypt that vdi.

Keep in mind that the keystore data may be held either in the guest's .vbox file (in the case of the whole guest getting encrypted via the main Virtualbox window) or in the global Virtualbox.xml file (if the drive file is encrypted with the vboxmanage command) in C:\users\{you}\.Virtualbox (on Windows hosts).

Check you Virtualbox.xml file. If you see the keystore there, post on a new topic and ask how to get the keystore and the drive into a guest.

[fth0]

@scottgus1:
Are you really sure that the KeyStore can be saved in the VirtualBox.xml file?

Background information: Before I wrote my older posts in this thread, I did experiment myself, and my conclusion was that the KeyStore is only saved in the running VBoxSVC process and in the .vbox files. I did a new experiment right now to confirm my results:

The VirtualBox Manager 5.2.34 is running on Windows 10 1903, to keep the VBoxSVC alive. I create a new vdi file using VBoxManage createmedium, encrypt it using VBoxManage encryptmedium, and list it using VBoxManage list hdds. Then I close the VirtualBox Manager, wait 10 seconds for VBoxSVC to exit, and repeat the VBoxManage list hdds command; the vdi file is not listed anymore. I start the VirtualBox Manager 5.2.34 (and implicitly VBoxSVC) again, and repeat the VBoxManage list hdds command; the vdi file is still not listed. The VirtualBox.xml file doesn't contain information about the vdi file either. What am I missing?