8.3 Guarded Fabric & Shielded Virtual Machines

Guarded Fabric & Shielded Virtual Machines

In traditional virtualization environments, the virtualization administrator (BUILTIN\Administrators or Hyper-V Administrators on the physical host) possesses unrestricted access to all guest virtual machines. A compromised hypervisor or malicious host administrator can attach debuggers, extract secrets from guest RAM, inspect unencrypted virtual hard disks (.vhdx), copy sensitive database files, or leverage PowerShell Direct and VMConnect to bypass guest operating system authentication.

To solve this vulnerability in high-security, multi-tenant, and regulated compliance environments, Windows Server provides Guarded Fabric and Shielded Virtual Machines. This architecture treats the physical host and virtualization administrators as untrusted entities, cryptographically isolating tenant workloads so that only authorized guest administrators can access the VM's data and runtime environment.

---

1. Guarded Fabric Architecture & Components

A Guarded Fabric consists of three core components:

1. Host Guardian Service (HGS): A clustered server role running in a dedicated, isolated Active Directory forest. HGS holds the keys and certificates required to unlock and run shielded VMs.
2. Guarded Hosts: Physical Hyper-V hosts equipped with specialized hardware (TPM 2.0, UEFI Secure Boot, virtualization extensions) that have been attested and authorized by HGS.
3. Shielded Virtual Machines: Generation 2 virtual machines with virtual TPM (vTPM) enabled and virtual hard disks encrypted using BitLocker, whose runtime state and memory are protected by the hypervisor.

+-----------------------------------------------------------------------------------------+
|                              GUARDED FABRIC ARCHITECTURE                                |
|                                                                                         |
|   +---------------------------------------------------------------------------------+   |
|   | HOST GUARDIAN SERVICE (HGS CLUSTER - ISOLATED FOREST)                           |   |
|   |                                                                                 |   |
|   |  [Attestation Service]                    [Key Protection Service (KPS)]        |   |
|   |  - Validates TPM 2.0 EK certs             - Holds Tenant Key Protectors         |   |
|   |  - Measures Boot Logs (TCG)               - Releases decryption keys ONLY when  |   |
|   |  - Enforces Code Integrity (CI) Policies    Attestation Service confirms health |   |
|   +------------------------+--------------------------------------------------------+   |
|                            ^                              |                             |
|             1. Attestation |                              | 2. Key Release              |
|                Validation  |                              |    (Encrypted Key)          |
|                            |                              v                             |
|   +------------------------+--------------------------------------------------------+   |
|   | GUARDED HYPER-V HOST                                                            |   |
|   |  - Hardware: TPM 2.0 + Secure Boot + IOMMU + Virtualization-Based Security (VBS)|   |
|   |                                                                                 |   |
|   |  +---------------------------------------------------------------------------+  |   |
|   |  | SHIELDED VIRTUAL MACHINE (Generation 2 Only)                              |  |   |
|   |  |  - Virtual TPM (vTPM) + BitLocker OS/Data Volume Encryption               |  |   |
|   |  |  - VMConnect (Console) BLOCKED | PowerShell Direct BLOCKED                |  |   |
|   |  |  - Encrypted VHDX Disks & Live Migration Traffic                          |  |   |
|   |  +---------------------------------------------------------------------------+  |   |
|   +---------------------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------------------+

---

2. Host Guardian Service (HGS) Internals & Attestation Modes

The Host Guardian Service acts as the security arbiter for the entire fabric through two internal services:

• Attestation Service: Interrogates candidate Hyper-V hosts attempting to start or run shielded VMs, evaluating hardware identity, boot state, and software baseline.
• Key Protection Service (KPS): Stores encryption keys and issues transport keys. KPS will never release keys to a Hyper-V host unless the Attestation Service explicitly validates that the requesting host is healthy and authorized.

Attestation Modes Comparison

Windows Server provides two primary attestation modes:

+-----------------------------------------------------------------------------------------+
|                         HGS ATTESTATION MODES COMPARISON                                |
|                                                                                         |
|   DIMENSION             TPM 2.0-TRUSTED ATTESTATION      HOST KEY ATTESTATION           |
|   --------------------+--------------------------------+--------------------------------|
|   Security Level      | Highest (Hardware-Rooted)      | Medium (Software/Key-Based)    |
|   Hardware Requirement| Physical TPM 2.0 + UEFI 2.3.1c | No TPM required (standard x64) |
|                       | + Secure Boot enabled          |                                |
|   Identity Mechanism  | TPM Endorsement Key (EK) cert  | Asymmetric Host Public Key     |
|   Integrity Validation| Measured Boot (TCG log) +      | None (Validates host identity  |
|                       | Code Integrity (CI) policy     | key only; no health check)     |
|   Recommended For     | Enterprise Production & Highly | Branch offices, legacy hardware|
|                       | Regulated Environments         | lacking TPM 2.0                |
+-----------------------------------------------------------------------------------------+

TPM 2.0-Trusted Attestation Baseline Components:

1. Endorsement Key (EK) Certificate: Proves the physical authenticity of the motherboard TPM chip.
2. Code Integrity (CI) Policy: An authorized binary policy file created via Windows Defender Application Control (WDAC). Ensures only signed, trusted kernel-mode drivers and hypervisor binaries execute on the host.
3. TPM Baseline (TCG Measured Boot Log): Captures PCR (Platform Configuration Register) measurements from the UEFI firmware, boot loader, and hypervisor initialization. Any unauthorized change to the BIOS/UEFI or kernel drivers alters the PCR values, causing attestation to fail immediately.

# ON THE GUARDED HOST: capture the TPM identifier (EKpub).
# Get-PlatformIdentifier takes -Name (mandatory) and RETURNS an XmlDocument --
# it does not write a file, so pipe .InnerXml to Out-File yourself.
(Get-PlatformIdentifier -Name 'HV-GUARD-01').InnerXml |
    Out-File 'C:\HGS\GuardedHost01_EK.xml' -Encoding UTF8

# ON THE HGS SERVER: register the Guarded Host EK certificate (one XML file per host)
Add-HgsAttestationTpmHost -Path "C:\HGS\GuardedHost01_EK.xml" -Name "HV-GUARD-01"

# ON THE HGS SERVER: add an authorized Code Integrity (CI) Policy
Add-HgsAttestationCiPolicy -Path "C:\HGS\GuardedHost_CiPolicy.bin" -Name "ProductionCIPolicy"

# ON THE HGS SERVER: add the TPM baseline captured from a reference host
Add-HgsAttestationTpmPolicy -Path "C:\HGS\ReferenceHost.tcglog" -Name "Contoso-Gen11-Baseline"

Exam trap -- Get-PlatformIdentifier has no -Path parameter. Its only parameters are -Name (mandatory), -CimSession, -ThrottleLimit and -AsJob, and it emits an XmlDocument object rather than writing to disk. -Path belongs to the HGS-side cmdlets that consume the resulting file (Add-HgsAttestationTpmHost, Add-HgsAttestationCiPolicy, Add-HgsAttestationTpmPolicy). If the EK is captured with the wrong syntax the XML file is never created and the subsequent Add-HgsAttestationTpmHost fails on a missing path. Remember the split: capture on the host with -Name, register on HGS with -Path plus -Name.

---

3. Shielded VMs vs Encryption Supported VMs

When securing virtual machines, Hyper-V supports two distinct VM protection policies configured under VM Settings > Security:

+-----------------------------------------------------------------------------------------+
|                     SHIELDED VMS VS ENCRYPTION SUPPORTED VMS                            |
|                                                                                         |
|   SECURITY FEATURE                 SHIELDED VM              ENCRYPTION SUPPORTED VM     |
|   -------------------------------+------------------------+-----------------------------|
|   Generation Requirement         | Generation 2 Only      | Generation 2 Only           |
|   Virtual TPM (vTPM)             | Mandatory              | Enabled (Optional/Mandatory)|
|   BitLocker Disk Encryption      | Mandatory (OS & Data)  | Supported (OS & Data)       |
|   VMConnect (Console Access)     | BLOCKED                | ALLOWED                     |
|   PowerShell Direct              | BLOCKED                | ALLOWED                     |
|   VHDX Inspection / Host Mount   | BLOCKED (Encrypted)    | BLOCKED (Encrypted)         |
|   Live Migration Traffic Encrypt.| Automatic / Mandatory  | Configurable                |
|   Host Attestation Enforcement   | Strict HGS Attestation | Runs on any Hyper-V Host    |
|                                  | Required               | if key protector permits    |
+-----------------------------------------------------------------------------------------+

The Shielded VM Security Boundary:

• Console Access Blocked: Host virtualization administrators cannot open a VMConnect console session to view the guest OS screen. Management must occur strictly over in-guest network protocols (RDP, SSH, PowerShell Remoting over IP).
• PowerShell Direct Disabled: Prevents the host OS from using VMBus communication channels to inject commands or run processes inside the guest without network connectivity.

4. Shielding Data Files (.pdk) & Provisioning Workflow

Provisioning a new Shielded VM requires creating a Shielding Data File (.pdk). The .pdk file is authored by the tenant or workload owner using the Shielding Data File Wizard or PowerShell, encapsulating all secrets required to deploy the VM securely onto an untrusted fabric.

+-----------------------------------------------------------------------------------------+
|                        SHIELDING DATA FILE (.PDK) CONTENTS                              |
|                                                                                         |
|   [SHIELDING DATA FILE (.pdk) - ENCRYPTED]                                              |
|   ├── Guardian Configuration: Identifies authorized HGS cluster guardian public keys    |
|   ├── Owner Guardian: Tenant's private/public key pair proving VM ownership             |
|   ├── Volume Signature Catalog (.vsc): Hash baseline of trusted signed template disks  |
|   ├── Unattend.xml: Automated specialization file containing:                           |
|   │   ├── Local Administrator password (encrypted)                                     |
|   │   ├── Domain-join credentials (encrypted)                                           |
|   │   ├── Static IP / Network configuration                                             |
|   │   └── Post-deployment startup run commands                                          |
|   └── RDP / SSH Public Certificates: In-guest administrative access keys               |
+-----------------------------------------------------------------------------------------+

Provisioning Steps:

1. Template Disk Preparation: A trusted Windows Server VHDX template is created, generalized via Sysprep, and signed with a digital certificate to generate a Volume Signature Catalog (.vsc) via Protect-TemplateDisk.
2. PDK Authoring: The tenant compiles the .pdk file using New-ShieldingDataFile, embedding the .vsc hash, guardian public keys, and encrypted unattend.xml.
3. VM Creation: The hosting provider or infrastructure team provisions the VM using the signed template disk and the tenant's .pdk file. The physical host never sees the plaintext local administrator password or domain credentials embedded in the unattend.xml.

---

5. Live Migration & Disaster Recovery of Shielded VMs

• Live Migration in a Guarded Fabric: When a Shielded VM Live Migrates between two guarded hosts, the target host must independently attest with the HGS cluster and obtain a valid health certificate. The VM memory state and execution registers are encrypted across the network using session keys negotiated with HGS.
• Cross-Fabric Migration & Disaster Recovery: To enable a Shielded VM to run in a secondary disaster recovery Guarded Fabric, the tenant administrator must append the secondary HGS cluster's Guardian certificate to the VM's Key Protector using Set-VMKeyProtector.

# Query the HGS client attestation status on a Guarded Host
Get-HgsClientConfiguration

# Test end-to-end HGS Attestation and diagnostic reachability
Test-HgsClientConfiguration