According to the high number of data breach that is targeting a well-known organization around the globe today, it’s imperative to start changing the way you think about security. We have to assume that data breach is not a position of pessimism, it’s one of security rigor.
Administrator privileges are under constant risk: Phishing Attacks, Stolen Admin Credentials and Insider Attacks, each of these attacks seeks out and exploits privileged accounts. Those privileges are being compromised through social engineering, bribery, hacking, etc.
When it comes to virtualization, virtual machines have their own problems, for physical hosts we relatively well know how to protect them, either we put them in a high secured room with access control with night vision security cameras, or whatever physical security measurement we are using.
Virtual machines bring an interesting vector to the whole story because they are mobile. The physical servers are mobile as well, but you would notice someone is carrying out a large server box or pulling a physical drive, but with virtual machines that is really hard and especially since it’s not physically removing the drives for example, but instead it’s copying, so you could think of someone simply copying over a VHD(X) file for SQL server or domain controller, and then doing offline analysis on that VHD(X) file, because you can just take it home with you on a flash drive, and the capacity of modern flash drives nowadays are really high and cheap.
The first virtualization response to this risk is by using Shielded virtual machines. Shielded VMs are really great, they provide encryption capabilities using virtual TPM, live migration and VM state are encrypted. Shielded VMs use health attestation to make sure these virtual machines can only be run on “healthy” hosts running known and trusted code, and the final protection is from administrators. Host administrators cannot access guest VM (i.e. can’t see disk), and they cannot run arbitrary kernel-mode code, however, shielded virtual machines are supported on generation 2 VMs only.
What about generation 1 virtual machines they are still out-there? Some people cannot use Gen2 VMs everywhere. There are valid reasons why Gen2 VM is not possible to be used, example with older operating system that do not support UEFI (WS 2008 or WS 2008 R2).
To address this limitation, Microsoft introduced Key Storage Drive (KSD) feature.
Key Storage Drive in Windows Server 2016
In Windows Server 2016 Hyper-V, Microsoft introduced a new feature called Key Storage Drive (KSD) for Generation 1 virtual machines only. KSD requires a special IDE device to be attached for each Gen1 VM that you want to protect. The default drive size is 42MB, why 42MB? because the minimum file size supported on various file systems is exFAT (42MB), thus will give you the option to use different file systems such as (exFAT, FAT32, or NTFS) if you need to. The content of the key storage drive is first compressed, encrypted and then stored as part of the virtual machine Runtime State.
The virtual machines with KSD are encrypted similar to Shielded VMs although, however, the key storage drive Gen1 VMs don’t have the same security assurances as Gen2 VMs (No secure boot, no measurement on the VM), but Microsoft is allowing using BitLocker to encrypt the disk within the guest.
With Key Storage Drive, you can also encrypt both live migration and VM state, however, these settings are not enforced for the virtual machine, so any administrator can simply remove the Key Storage Drive and then by discarding the content of the KSD from the virtual machine, and of course you could still tamper with the general configuration of the virtual machine, you could add a separate disk for example and since we don’t have secure boot no measurement in the VM, the second added disk could then be booted up and access the content of the Key Storage Drive. It’s very important to understand that Gen1 VM with KSD does not have high security assurance like shielded VMs.
Please note that KSD does not protect against the administrator fabric or the Hyper-V host as we have with shielded VMs, however, KSD helps protecting against the administrators that have access to the storage only, because the storage admin and the KSD case simply sees an encrypted disk, they cannot inspect it and they cannot do the same attack vector that the Hyper-V administrator can do.
The good news is, that you still have the same infrastructure “Attestation of health” in place as you do with shielded virtual machines, so that the host before the key storage drive can be decrypted and the VMs started up, the host has to attest to its health and provide health certificate to obtain the key to access of the KSD.
Virtual machines with KSD can be useful in two deployment scenarios:
- Enterprise private cloud: When protecting virtual machines from offline attacks.
- Compliance: If you are really skeptical, KSD is really useful for tenants and enterprises in order to meet data protection related regulatory or compliance requirements. The disk is also encrypted on backup, so backup vendors for example if you have third-party that runs the backup for you, they cannot really gain any insight into your virtual machines.
How to add a Storage Key Drive
As mentioned earlier, KSD is supported only on Gen1 VM. In order to add a key storage drive, you need to make sure the VM is turned off, since an IDE device can only be added when the VM is in offline state.
Right click on a VM in Hyper-V Manager and then select Settings.
Under the VM settings, select Security and then click on Add Key Storage Drive as shown in the following screenshot:
By adding the Key Storage Drive, you switched on the virtual machine state encryption when written to disk and encrypting the virtual machine migration traffic as well.
As you can see in the following screenshot, KSD is automatically added to the virtual machine.
You also need to make sure that you added the necessary key protector for the Key Storage Drive similar to shielded VM concept. The Key protector is basically in this specific case points to a host guardian service infrastructure, later on this in the next section.
In the next step, turn on the virtual machine and login to the guest OS.
In order to start BitLocker encryption, you need to allow BitLocker to encrypt the drive without a TPM present, for this reason, you need to open local group policy inside the guest by typing (gpedit.msc) and enable the following group policy as shown in the next screenshot:
| Computer Configuration | Administrative Templates | Windows Components | BitLocker Drive Encryption | Operating System Drives | Require additional authentication at startup | Enabled |
After you enable the group policy, please make sure to force the policy by running: gpupdate /force
In the second step, you need to open command prompt inside the guest OS and type the following commands:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
C:\>diskpart DISKPART> list disk DISKPART> select disk 1 DISKPART> create partition primary DISKPART> format fs=ntfs label=KSD quick DISKPART> assign letter=k DISKPART> exit |
Disk 1 is the Key Storage Drive with 42MB disk space in this example. Then we formatted the disk, give it a label= “KSD” and assigned a drive letter= “K”.
The final step is to install BitLocker feature and start the encryption by running the following commands:
|
1 2 3 |
PS C:\> Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart -Verbose PS C:\>Manage-bde -on C: -StartupKey K:\ -UsedSpaceOnly -SkipHardwareTest |
Please note that if you’re using fixed disks instead of dynamic VHD(X), you don’t need to add -UsedSpaceOnly parameter.
BitLocker will kick off as shown in the following screenshot and the OS disk will be encrypted.
Host Guardian Service and Guarded Hyper-V Hosts
The entire guarded fabric infrastructure as shown in the following diagram contains the Host Guardian Service (HGS). The host guardian service is a standard Windows Server 2016 role, it provides attestation and key protection service. However, on the different guarded Hyper-V hosts, there is a separate feature that needs to be installed which is the “Host Guardian Hyper-V Support” feature and that allows the guarded host to be preferred to communicate with the host guardian service.
Guarded Fabric Infrastructure Windows Server 2016 Hyper-V [image courtesy: Microsoft]
Let’s now illustrate the process when a VM is startup on a guarded host.
In this specific case it’s a virtual machine with Key Storage Drive added, and what the host then has to do, is to obtain a health certificate from the host guardian service, it does so by either sending a Kerberos ticket or by sending a policy measurement for code integrity policy and boot process to the host guardian service attestation service.
The host guardian service validates whatever has sent by the guarded Hyper-V host and matches what is expected for the specific host and then issues a health certificate. With this health certificate, the guarded Hyper-V host can then request the key to unlock the Key Storage Drive in this specific case, or a virtual TPM in a shielded virtual machine case.
The host guardian service confirms the VM if it’s authorized to run on this fabric, and returns a decryption key to the guarded Hyper-V host. In the final step, the Key Storage Drive is decrypted and the VM can boot.
Microsoft has released two attestation modes:
- Hardware-trusted Attestation
- Complex setup
- Newer hardware, Hyper-V host requires TPM 2.0 and UEFI 2.3.1
- Highest level of assurance
- No local admin access
- Admin-trusted Attestation
- Simplified setup by setting up an Active Directory trust and trusted hosts group
- Existing hardware likely sufficient
- Weaker level of assurance
- Local admin access possible
Since the host guardian service is a critical role, Microsoft recommends to setup at least 3-nodes cluster. The host guardian service supports high availability configuration through scale-out.
As of this writing, for every HGS node, Microsoft recommends to have 1 physical machine with TPM and secure boot is enabled. Virtualizing the host guardian service is not supported.
As for the guarded Hyper-V hosts, any hardware that is capable to run Windows Server 2016 Hyper-V for admin-trusted attestation or TPM 2.0 with UEFI 2.3.1 for hardware-trusted attestation.
As from the Software perspective, the hosts must be Windows Server 2016, however, the guest OS can be Windows Server 2012 and later for shielded VMs. As of this writing, System Center Virtual Machine Manager 2016 is an optional management component and supports only shielded VMs, however, Key Storage Drive is not supported yet in VMM.
Conclusion
If you are still using Generation 1 virtual machines in your environment today, it’s the time to start revisiting the policies and procedures dictated by your company in order to increase the level of security of your services.
If for any reason your workload does not support newer operating system to leverage shielded VMs, you can still encrypt those legacy OSes with KSD. I highly recommend to move all your services to Generation 2 VMs when possible.
Key Storage Drive allows BitLocker encryption for Generation 1 VMs by leveraging the same core guarded fabric infrastructure discussed in this post. But, KSD does not provide security assurances like shielded VMs.
Until next time…
Thanks for reading!
