Code Library

Today, in most virtual environments there are many types of administrators who have access to VM
assets, such as storage. That includes virtualization administrators, storage administrators, network
administrators, backup administrators, just 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. Keep in mind that this protection from administrators is needed for a number of reasons.

Here are just a few:

 Phishing attacks
 Stolen administrator credentials
 Insider attacks

Shielded VMs provide protection for the data and state of the VM against inspection, theft, and tampering from administrator privileges. Shielded VMs work for Generation 2 VMs that provide the
necessary secure startup, UEFI firmware, and virtual Trusted Platform Module (vTPM) 2.0 support
required. Although the Microsoft Hyper-V hosts must be running Windows Server 2016, the guest OS in the VM can be Windows Server 2012 or above.

A new Host Guardian Service instance is deployed in the environment, which stores the keys required for an approved Hyper-V host that can prove its health to run shielded VMs.

A shielded VM provides the following benefits:
 BitLocker encrypted drives (utilizing its vTPM)
 A hardened VM worker process (VMWP) that encrypts live migration traffic in addition to its runtime state file, saved state, checkpoints, and even Hyper-V Replica files
 No console access in addition to blocking Windows 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? First, it’s important that the Hyper-V host has not been compromised
before the required keys to access VM resources are released from the Host Guardian Service (HGS).
This attestation can happen in one of two ways. The preferred way is by using the TPM 2.0 that is
present in the Hyper-V host. Using the TPM, the boot path of the server is assured, which guarantees
no malware or root kits are on the server that could compromise the security. The TPM secures communication to and from the HGS attestation service. For hosts that do not have a TPM 2.0, an
alternate Active Directory–based attestation is possible; however, this merely checks whether the host is part of a configured Active Directory group. Therefore, it does not provide the same levels of
assurance and protection from binary meddling and thus host administrator privileges for a
sophisticated attacker. However, the same shielded VM features are available.

After a host undergoes 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 then be used to decrypt the vTPM to make it possible for 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 turn on the VM’s access to the encrypted storage (not the administrator, though, as the virtual hard drive (VHD) remains encrypted on the drive).

At this point, it might be self-defeating: If I am an administrator on the Hyper-V and the keys are
released to the host to start the VM, I would be able to gain access to the memory of the host and
get the keys, thus nullifying the very security that should protect VMs from administrative privileges.
Fortunately, another new feature in Windows 10 and Windows Server 2016 prevents this from
happening. This feature is the protected enclave mentioned earlier, which is known as Virtual Secure
Mode (VSM). A number of components use this service, 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; rather, think of it like a small virtual safe that is protected by virtualization based on technologies such as Second Level Address Translation (SLAT) to prevent people from trying to directly access memory, I/O Memory Management Unit (IOMMU) to protect against Direct Memory Access (DMA) attacks, and so on. The Windows operating system, even the kernel, has no access to VSM. Only safe 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, the health check would fail, and the keys would not be released to the host. Remember I mentioned the keys from the key protection service are sent encrypted? It's the VSM that decrypts them, always keeping the decrypted key protected from the host OS.

When you put all of 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 will close a security
hole many environments cannot close today.

Source of Information : Microsoft Introduction Windows Server 2016