Is it cryptographically safe to use veracrypt in a virtualbox virtual machine?

Question

Does virtualbox provide enough entropy (random numbers) for the veracrypt program on the virtual machine? Is it cryptographically safe to use veracrypt inside a virtualbox in a windows 10 guest?

Answer 1

According to this question modern VMs have access to "the CPU instruction RDRAND" which provides high quality random data.

This suggests that yes, you can safely use VeraCrypt inside a VM. However, the significant caveat is that you must trust the host machine. If an attacker has full control over the host machine, they have full control over the VM.

Answer 2

You can determine the level of security you have with Veracrypt (or any other encryption software) within a Virtual Machine, by using logical deduction, and considering (realistically) what hypervisor data files are modified by the Hypervisor when data is accessed and/or written to and from, when a storage device within a Hypervisor guest is modified.

Consider, that contrary to popular belief, not every user/system action that occurs is recorded by the hypervisor. If that were the case, the configuration and log files the hypervisor uses would be at least the same size as the guest OS and data files. That is certainly not the case as it would be an enormous waste of valuable disk space.

So Hypervisors track, and log only the data needed to accommodate hardware and software state change. Hypervisors do not concern themselves with the state of the data itself, only the storage medium as it relates to its hardware state.

So if, for example, you create a Vercrypt standard volume (as a file) and save data within that container, utilizing good solid password and encryption practices, that data will be secure from attacks based upon any data found in the Hypervisor logs and conf files.

(Note: SSD data is only considered safely encrypted if the entire disk is encrypted, due to the way that SSD's write data to the memory locations. Put simply SSD's firmware writes data to memory locations based upon best performance and drive longevity, so the weakness is that it may write data outside of the encrypted container memory space. When you have the encrypted container open and are writing data to it, the data is not encrypted. It is encrypted within the container on close. So the SSD could potentially write data (in the clear) to unencrypted memory spaces, and that data would be ripe for exploit. Not a great explanation but it's the gist. So for highly sensitive data I always use either HDD (for containers) or a fully encrypted SSD drive. By full encryption I mean no partitions, choose the device itself and encrypt the device despite the warnings about data loss that Veracrypt will give you)

All that said, in a virtual environment the guest O.S. itself would be the weak point to be exploited. Windows 10 for example, gathers so much user activity based data, that believing for even a second that ANY encrypted container is safe from exploit is foolhardy. The sad fact of the matter is that Microsoft's decision to embed with the government and actively gather massive amounts of user activity data (while not allowing any kind of true opt out option) makes Windows 10 the most insecure, ridiculous mess ever coded. Just the basic user activity data Microsoft reserves the right to collect and transmit via the internet back to MS servers, is a list over 80 pages long. See: Well sorry but the list has been deleted from the Microsoft site which is no surprise. If you really want the list it's out there if you google it. I have it somewhere if you pm me I can send you a copy Any rate anyone that thinks their data is safe on Windows 10 is blindly trusting MS and that pure folly. That's why I dumped Windows and only run Linux now.

Long story longer, when it comes to security of the data within a virtual guest there are a lot of areas to consider other than simply the Guest OS and the storage media.

One must consider the networking involved, and user behavior.

For one of my clients (a law office) they had the need for portable VM guests that they could use to deal with individual clients data.

So I created Windows 7 Guests that are disposable. Each guest has the os .vdi virtual disk and a second .vdi disk for data. Inside the data .vdi is and encrypted volume. I wrote a batch file that shreds everything but the data .vdi when they are through with it. They use vpn client to connect to the main office, with no split tunnel, and the guest nic is in Bridged Mode.

That is about the best you can do to secure vm guest data without going all spy vs. spy. Truth is at the end of the day the goal is to protect the data from the average hacker. If the NSA or a government entity wants the data, they will get it one way or another.

Hacking Veracrypt can be done I'm sure, but if you use a good random very long password, and solid encryption scheme, most hackers will not be able to access the data unless that had a keylogger watching you when you created it, or when you open it.

User behavior comes down to making sure to use strong passwords, use care when entring your passwords (prying eyes etc...) and do not leave encrypted volumes open when not in use.

As for the underlying technology of the virtual disks themselves, they are data, and they store the data using encryption, in encrypted data space (on close), so I do not see an exploit condition there. Fair minds could argue, and I always advise considering all available opinions when it comes to security as long as they are reasonable, and logical.

So often when it comes to data security we lose sight of the forest for the trees. A perfect example is the ongoing argument about the "Plausible Deniability" of hidden volumes. I listed to both sides hashing out the minutia in the Veracrypt forums a couple of years ago, and came to the conclusion that none of them really understood the legal concept itself, and how it is applied in a court of law. So end of the day it's as simple as this, even if a lawyer presents strong evidence that a hidden container existed, that does not necessarily undermine plausible deniability when it comes to encrypted data, because one does not deny the existence of encrypted containers, but rather that you have a password that will actually open the container. So many errors can cause a password to not open a container, that the very idea that anyone could prove you know the password to a hidden container is total horse... bologna. Simple as, "My client created a hidden container for testing purposes testing, but then he wrote to much data to the main container and damaged the hidden container and hasn't they haven't been able to open it since. The last password that worked was p@ssword123kissmybuttandcallitalovesong.