What is Key Storage Drive in Windows Server 2016 Hyper-V?

Posted by Charbel Nemnom on October 13, 2016
Share on Facebook0Share on Google+0Share on LinkedIn2Share on Reddit0Tweet about this on Twitter0
5/5 (1)

usb key


Security is a critical requirement of any organization’s system. With the release of Windows Server 2016, Microsoft puts a lot of efforts around security and added a lot of new features. One hot feature that will add a lot of benefits to any small, medium and enterprise business environments is Shielded Virtual Machines and Key Storage Drive (KSD). Be sure that’s going to help you to increase the security whether you are a service provider or enterprise customer.

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:

Settings for WSUS

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.

Settings for WSUS

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

Require additional authentication at startup

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:

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:

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.

Encryption of OS disk


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


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.


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!

Related materials:

Views All Time
Views Today

Please rate this

Return to all posts

The latest updates in vSphere 6.5 and VSAN 6.5
Active Directory needs a revision
The following two tabs change content below.
Charbel Nemnom
Microsoft MVP Charbel Nemnom is an accomplished, hands-on technical professional with over 13 years of broad IT project management and infrastructure experience serving on and guiding technical teams to optimize performance of mission-critical enterprise systems. He is an excellent communicator, adept at identifying business needs and bridging the gap between functional groups and technology to foster targeted and innovative systems development. Charbel is well-respected by peers through demonstrating passion for technology and performance improvement. He has extensive practical knowledge of complex systems builds, network design and virtualization. Charbel has extensive experience in various systems, focusing on Microsoft Cloud Platform, Hyper-V, Datacenter Management, Cloud Computing, security, data protection, and many types of monitoring tools as well as a solid knowledge of technical reporting. Technical reviewer of the book Hyper-V Best Practices by Packt Publishing.