Q. What are shielded VMs in 2016 Hyper-V?
A. Today in most virtual environments there are many types of administrator who have access to virtual machine assets such as their storage. That includes virtualization administrators, storage administrators, network administrators, backup administrators to name just a few. Many organizations including hosting providers need a way to secure VMs even from administrators which is exactly what shielded VMs provides. Note that this protection from administrators is needed for a number of reasons:
- Phishing attacks
- Stolen administrator credentials
- Insider attacks
Shielded VMs provides protection for the data and state of the VM against inspection, theft and tampering from administrator privileges. Shielded VMs works for Generation 2 VMs that provide the necessary secure boot, UEFI firmware and virtual TPM (vTPM) 2.0 support required. While the Hyper-V hosts must be running Windows Server 2016 the guest operating system in the VM can be Windows Server 2012 or above and, shortly after its release, even Linux.
A new Host Guardian Service instance is deployed in the environment which will store the keys required to run shielded VMs for authorized Hyper-V hosts if they can prove they’re healthy.
A shielded VM provides the following benefits:
- BitLocker encrypted disks (keys protected by its vTPM)
- A hardened VM worker process (VMWP) that helps prevent inspection and tampering
- Automatically encrypted live migration traffic as well as encryption of its runtime state file, saved state, checkpoints and even Hyper-V Replica files
- No console access in addition to blocking PowerShell Direct, Guest File Copy Integration Components and other services that provide possible paths from a user or process with administrative privileges to the VM
How is this security possible? Firstly, it’s important that the Hyper-V host has not been compromised before the required keys to access shielded VMs are released from the Host Guardian Service (HGS). The health of the host is measured in a process called attestation which can happen in one of two ways: TPM-based attestation or Active Directory-based attestation. The preferred and strongest way is using TPM attestation which requires a TPM 2.0 (earlier TPMs are not supported) in the Hyper-V host. Using secure boot and the TPM the boot path and code integrity policy of the server are assured which guarantees no malware, root kits or unapproved software are on the server that could compromise the security. The TPM is also used to secure communication to and from the HGS attestation service. For hosts that do not have a TPM 2.0 an alternate AD-based attestation model is possible. However, this merely checks if the host is part of a configured AD group and does not provide the same levels of assurance and protection from binary meddling or abuse of host administrator privileges for a sophisticated attacker, the same shielded VM features are available, though.
Once a host has undergone attestation it receives a health certificate from HGS’ attestation service that authorizes the host to get keys released from the key protection service that also runs on the HGS. The keys are encrypted during transmission and can only be decrypted within a protected enclave that is also new to Windows 10 and Windows Server 2016 (more on that later). These keys can then be used to decrypt the vTPM which, in turn, enables the VM to access its BitLocker protected storage and start. Therefore, only if a host is authorized and healthy will it be able to get the required key and enable the VM’s access to the encrypted storage (not the administrator though as the VHD still stays encrypted on disk).
At this point it may seem like if I am an administrator on the Hyper-V host and the keys to start the VM are released to the host then I would be able to access to the memory of the host and get the keys therefore defeating all of this new security. Another new feature in Windows 10 and Windows Server 2016 stops this happening, this is the protected enclave mentioned earlier which is known as Virtual Secure Mode (VSM) and is used by a number of components including credential guard. Virtual Secure Mode is a secure execution environment where secrets and keys are maintained and critical security processes run as Trustlets (small trusted processes) in a secure virtualized partition. This is not a Hyper-V VM but rather think of it like a small virtual safe that is protected by virtualization based technologies such as SLAT and IOMMU to protect against memory and DMA attacks and so on. The Windows OS, even the kernel, has no access to VSM. Only whitelisted processes (trustlets) that are Microsoft signed are allowed to cross the “bridge” to access VSM. A vTPM Trustlet is used for the synthetic TPM device of each shielded VM and is separate from the rest of the VM process which runs in a new type of protected VM worker process. This means there is no way to access the memory used to store these keys even with complete kernel access. If I'm running with a debugger attached, for example, that would be flagged as part of the attestation process and the health check would fail ensuring that the keys are not released to the host. Remember I mentioned the keys from the key protection service are sent encrypted? It's in VSM where they are decrypted always keeping the decrypted key protected from the host OS.
When you put all this together you have the ability to create a secure VM environment that is protected from any level of administrator (when using TPM 2.0 in the host) and closes security holes that many environments cannot come close to defending today.
