This is another small article in my Bitlocker article series.
It is about encrypting virtual machines.
The scenario that I am securing the VM against, is that an attacker has physical access to the host and is trying to read out the virtual hard drive of the guest systems.
If an attacker gets physical access to your hypervisor host server, he can probably read the data of several important servers at a time. Using encryption on hypervisors is absolutely mandatory. Let me show you 3 ways of securing your windows VMs by means of Bitlocker.
So how would this attacker proceed? If he manages to logon to the hypervisor, he will surely find his way to the machines, unless their storage is encrypted. Best would be, to encrypt the hypervisor-OS and also the whole physical storage. If you can't encrypt the whole storage for one reason or the other, you should try to encrypt at least the virtual hard drives. Encrypting these will, of course, require additional steps as soon as we use the VMs as real servers, able to restart on their own without needing someone to supply an encryption key. This sounds like a job for a TPM chip, a virtual one!
Depending on your hypervisor, you may already have access to virtual TPMs ("vTPM"). For example, Hyper-V has been offering that for many years. So please check whether your hypervisor offers this and what requirements need to be met. Possibly, you will have to upgrade your hypervisor, or switch to a different one altogether.
For this article, I will be s
ticking with Hyper-V
and show you how it’s done with a windows 10 guest machine. I am using Hyper-V on Windows 10, 1909, here.
When creating a machine, you will need to make it a Gen2 machine – else, the option to add a vTPM to the VM is not available!
So we create a VM and then simply choose the following options:
The other two check boxes are optional and not needed for Bitlocker to function.
Afterwards, you simply boot the machine and turn on Bitlocker just like you would with a physical machine. Please note that despite having a virtual TPM, you don’t need to consider anything else – as long as you keep the recovery password, that Bitlocker GUI setup will display by default, in a safe place, you may even export this VM to another host and combine it with another vTPM – no problem.
OK, now for the interesting question “what if my hypervisor does not offer a vTPM?”
It needs to be said that Microsoft did not use to support Bitlocker on virtual machines unless you use it with a vTPM. However, from what I read in this
, they seem to have changed their mind. Anyway, what I describe here is technically possible and stable. So if you have for example a Gen1 machine (which, as said, does not offer to add a vTPM), how do you proceed?
First of all, you will need to configure Bitlocker not to require the presence of a TPM. This is done by configuring a GPO as seen in the
Step 2 is to create a tiny virtual hard drive (using the Hyper-V add-hardware-wizard) and place it on the share of another physically secured server (I will tell you why this is so important in a while). Set its (dynamically expanding) hard drive to the smallest possible
: 1 GB.
After adding this drive, start windows and format it, so that it appears as a drive letter (say e:).
OK, now let’s encrypt your VM's c: drive using a bitlocker encryption key (.bek file) and save it to this disk using this command on an elevated command line:
manage-bde -on c: -used -s -rp -sk e:\
OK, as you can see, the screen says, an encryption key was saved to drive e:\, that means whenever that drive e: is connected, the VM will unlock and start hands-free. Remove drive e:, and the VM will not boot hands-free, but instead ask for “the USB drive that has the Bitlocker key” (which is the virtual drive) and alternatively requires entering the 48-digit recovery password, which no attacker is able to break – see the following picture:
Now you might understand the reason why the small virtual hard drive that contains the key needs to be saved to a share of a different, physically secured server… if the attacker had access to that key, he would have access to the VM. Since Hyper-V runs as a system account, you would grant access permissions to that share only to admins and the system account of the hyper-v server.
Good, now for the last part – you may have noticed that the key is a visible file on drive e: of our VM (as soon as we tell explorer to show both hidden and system files) and thus would be possibly accessible by non-admin users of that virtual machine.
There are two ways to deal with this:
1st: remove access to drive e: itself by means of NTFS ACLs.
2nd: remove the drive letter of drive e:
Since both ways are just a few clicks or code lines, I recommend to do both using these commands on an elevated command prompt (adapt the user names to your language):
icacls e:\ /remove:g "authenticated users"
icacls e:\ /remove:g "users"
Now remove the drive letter as well:
sel volume e
As you can see, Windows has now removed the mount point – e: is no longer even visible.
Let me summarize the three ways that I have shown you:
1 encrypt both the hypervisor OS and the whole physical storage
2 if you cannot encrypt the physical storage, use a virtual TPM together with Bitlocker in order to encrypt the virtual hard drives of each VM or
3 if the requirements for vTPMs cannot be met, use a Bitlocker encryption key file on a virtual hard drive placed on a share of a physically secured server
That’s all for now!
If you have questions about the process, feel free to contact me or ask a related question here on EE!