Share via

How Shielded VMs make Hyper-V Environment Secure

  • Article

While talking about virtual environments, one may come across many types of administrators having access to assets of virtual machines like their storage. That comprises of network administrators, storage administrators, virtualization administrators and backup administrators etc. Many enterprises as well as hosting providers always choose a way for securing VMs even from administrators and that is what basically shielded VMs offer. However, the question arises as to why such protection is needed from administrators? The reasons are

  • Insider attacks
  • Phishing attacks
  • Stolen administrator credentials

Shielded VMs help in protecting the data and delivering a state in which the VMs are protected against theft, inspection and interference caused from administrator’s honors. VMs of generation 2 works well with shielded VMs as they provide the indispensable secure boot, virtual TPM (vTPM) 2.0 and UEFI firmware support needed. While Windows Server 2016 must be deployed in Hyper-V hosts, in VMs guest operating system can be of Windows Server 2012 or above and as Microsoft has announced after sometime even Linux will work.

A newly developed Host Guardian Service instance is installed in the environment storing the keys required to effectively function shielded VMs for Hyper-V hosts which are authorized.

Benefits of shielded VMs

  • A hardened VM worker process which helps in preventing tampering and inspection.
  • Console access is blocked along with blocking Guest File Copy Integration Components, PowerShell Direct as well as other services providing potential paths with administrative rights to the VM from a user or process.
  • Disks encrypted with BitLocker (keys protected by vTPM)
  • Live migration traffic is automatically encrypted and providing encryption of saved state, checkpoints, runtime state file and even Hyper-V Replica documents.

How Shielded VMs can enhance efficiency?

It is essential that Hyper-V hosts should not be compromised before the keys required to access the VMs are released from the HGS (Host Guardian Service). A process called attestation is carried out in order to determine the health of the host. The two ways to measure and determine the health of the host are Active Directory-based attestation or TPM-based attestation. The strongest and the preferred process is TPM attestation requiring TPM 2.0 in the Hyper-V host. Server’s code integrity policy and boot path are assured by using TPM and secure boot guaranteeing no unapproved software, malware or root kits are present on the server compromising security. One more advantage of TPM is that in order to secure communication from and to HGS attestation service, TPM is used. Where TPM 2.0 is not available, those hosts can use an alternate AD-based attestation model. This will just check is the host is part of a configured AD group and not providing the same level of protection and assurance abuse of host administrator privileges or binary interfering for a refined attacker. However, one can expect same features of shielded VM.

When the host has received attestation, a health certificate is issued from HGS attestation service giving the authorization to the host in order to release the keys from the key protection service that also functions on HGS. It is during the transmission that the keys are encrypted which can be decrypted in a protected enclave which is altogether new to Windows Server 2016 and Windows 10. The vTPM can be decrypted with these keys enabling the VM to access BitLocker protected storage and start. Therefore, it is important that the host must be authorized and healthy in order to get the required keys so that the VMs can access encrypted storage.

If you are the administrator on the Hyper-V host and the keys are released to the host with which the VMs are started then you can access the memory of the host and obtain the keys thereby defeating the new security. Another new feature in Windows Server 2016 and Windows 10 is Virtual Secure Mode (VSM), a number of components use this, credential guard being one of them. Virtual Secure Mode is an execution environment which is completely secured where keys and secrets are maintained. Moreover, like Trustlets, critical security processes are operated in a virtualized partition which is again secured. Many think that this is a Hyper-V VM, but the fact is, it is not. Assume that it is a small virtual safe which is protected by virtualization dependent technologies like IOMMU and SLAT in order to protect against DMA and memory attacks etc. The Operating System of Windows, not even the Kernel has access to VSM.

Only trustlets which are whitelisted processes, signed by Microsoft are permitted to walk over the bridge to access VSM. Synthetic TPM device of every shielded VM uses a vTPM Trustlet which is different from the VM process running in a protected diverse type of VM worker process. This signifies that there is no way to access the memory where keys are stored even with whole kernel access. If suppose, you operate with a debugger attached then as a part of the attestation process it would be flagged and the health check will fail signifying the host has not received the keys. From the key protection service the keys are sent encrypted. They are decrypted in the VSM protecting the decrypted key from the host OS.

Keeping all these things, a secure VM environment can be created which is sheltered from administrator of any level and patches security holes so that multiple environments cannot come nearby to it.