It’s important that the Hyper-V host has not been compromised before the required
keys to access VM resources are released from the HGS. This attestation can happen
in one of two ways. The preferred way is by using the TPM 2 that is present in the
Hyper-V host. Using the TPM, the boot path of the server is assured, which guarantees
that no malware or root kits are on the server that could compromise the security. The
TPM is used to secure communication to and from the HGS attestation service. For
hosts that do not have TPM 2, an alternate AD-based attestation is possible, but this
merely checks whether the host is part of a configured AD group. Therefore, this does
not provide the same levels of assurance and protection from binary meddling or host
administrator privileges for a sophisticated attacker, although the same shielded VM
features are available.
Once a host has gone through the attestation, it receives a health certificate from the
attestation service on the HGS 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 be decrypted only within a protected enclave that is new to
Windows 10 and Windows Server 2016 (more on that later). These keys can be used to
decrypt the vTPM content in the VM’s VMRS file, which is then used to hydrate the
VM’s synthetic TPM to enable the VM to access its BitLocker-protected storage and
start the VM. Therefore, only if a host is authorized and noncompromised 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, and the keys
are released to the host to start the VM, then I would be able to get access to the
memory of the host and get the keys, thereby defeating this security that should
protect VMs from administrative privileges. Another new feature in Windows 10 and
Windows Server 2016 stops this from happening. This is the protected enclave
mentioned earlier, which is known as Virtual Secure Mode (VSM) and is used by
various components including credential guard. VSM is a secure execution
environment in which 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 as a small, virtual safe that is protected by
virtualization-based technologies such as SLAT to stop people from trying to access
memory directly, IOMMU (Input-output memory management unit) to protect
against 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 vTPM of each VM,
separate from the rest of the VM process, which runs in a new type of protected VM
worker process. This means that 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 and the keys would not be released to the host. Remember I
mentioned that the keys from the key-protection service are sent encrypted? It’s the
VSM where they are decrypted, always keeping the decrypted key protected from the