In this blog post, I’ll walk you through the new features which are relevant to the PAW solution in the latest Windows 10 1803 release.

Offline HGS

Prior to 1803 release, to start a shielded VM, the host must connect to the HGS server in order to perform health attestation. One of the top customer feedback is that, PAW devices are sometimes in an offline mode, which means it does not have access to any network, or unable to connect to the HGS server, yet it is important to support the user to access the shielded VM at any time. We introduced the Offline HGS feature in the 1803 release to support this scenario. At high level, if the host health has not changed, shielded VM can start without connecting to the HGS server. That is, when the PAW device is unable to connect to the HGS server, as long as the device health matches previously attested state, it can used a copy of the cached key protector to unlock the shielded VM. The device must connect to the HGS server first to attest its health state before it can function at offline state. You can find the details on how to configure it here.

Lock PAW VM to the device

A shielded VM can start on a host device after the device can attest its health to the correct HGS server. To further secure the VM, ensure only the owner of the VM can start it, we added a policy to lock the shielded VM on the device where it is created. This is a policy controlled by the administrator, the setting is stored in the shielding data file, and it will be enforced at the shielded VM creation time.

New-ShieldingDataFile [-ShieldingDataFilePath] <string> [-Owner] <Guardian> [-VolumeIDQualifier] <VolumeIDQualifier[]> [-AnswerFile] <NamedFileContent> [[-OtherFile] <NamedFileContent[]>] [[-Guardian] <Guardian[]>] [-Policy {Shielded | EncryptionSupported}]  [-BindToHostTpm <bool>] [-WhatIf] [-Confirm]  [<CommonParameters>] 

By setting the BindToHostTpm to true, the shielded VM will only start on the device where it is created. This is to prevent a case where an insider tries to steal a shielded VM and attempts to get it started on a different PAW device. This feature will also prevent shielded VM to migrate to another device. For the PAW scenario, you would want to ensure the data is not only stored locally, but also backed up or synced to the backend servers. In case of a hardware device failure, a new shielded VM can be provisioned and data can be restored.

VMConnect to shielded VM

VMConnect was previously blocked to connect to the shielded VM. In the PAW scenario, the user owns both device and the shielded VM, using VMConnect is another top request. After extensive security review, we enabled the support of VMConnect to shielded VM without lower the security assurance.

Get VM EKpub from the device host

Shielded VM has vTPM, which has the same characteristics of a physical TPM including the presence of EKpub. EKpub is used by in various attestation methods such as TPM key attestation. In the physical TPM scenario, the TPM EKpub is retrieved through a different channel and compared with the value from the device, this is to ensure the device TPM has not been tampered with and used as an immutable ID. For the shielded VM case, we added a channel to retrieve its EKPub from the host, the value can be compared with the EKPub retrieved from inside the VM to ensure its integrity and identity. The VM EKpub information is stored in the eventlog channel “Microsoft-Windows-Hyper-V-Worker-Analytic”, with Event ID 1500.  The event gets generated every time the shielded VM powered on.

Conclusion

As we continue to make the solution better, we welcome your feedback. In my next blog post, I’ll share the new networking capabilities in the insider release.