Hyper-V vTPM Devices¶
Windows / Hyper-V Server Technical Preview introduced the ability to attach vTPM devices to the Hyper-V VMs, offering the users the posibility to use it to enhance their security and system integrity.
Currently, there Hyper-V Driver doesn’t support adding vTPM devices to instances. This blueprint is addresing this issue.
Trusted Platform Module (TPM) technology is designed to provide hardware-based, security-related functions and it includes multiple security mechanisms to make it tamper resistant. Some of the key advantages of using TPM technology are:
Generate, store, and limit the use of cryptographic keys.
Use TPM technology for platform device authentication by using the TPM’s unique RSA key, which is burned into itself.
Help ensure platform integrity by taking and storing security measurements.
TPM-based Virtual Smart Card.
The shielded VMs make use of the vTPM devices. Shielded VMs should be used in cases where the security of the spawned instance is essential. They are encrypted (BitLocker or other means), ensuring that the only the designated owners can access the virtual machine. 
A few features of the Shielded VMs are:
Cannot inspect the disks.
Cannot inspect the memory.
Canoot inspect the processes.
Cannot attach debuggers to the system.
Cannot change the configuration.
In short, even if the administrator of the hypervisor host is compromised, all the existent virtual machine data is safe.
For more information and use cases for vTPM, check the References section .
This feature is not available in earlier versions than Windows / Hyper-V Server Technical Preview. vTPM devices cannot be created on an earlier version.
If the given instance requires a vTPM device but it does not contain the
hw_machine_type=hyperv-gen2 image property, the instance creation will
fail, as vTPM can be only added for Generation 2 VMs. Generation 2 VMs were
introduced in Windows / Hyper-V Server 2012 R2 and support for them was
introduced in the Kilo release (see Dependencies section).
As vTPM is not supported by all guests, enabling it for instances that do not
support it is pointless. Thus, creating instances with vTPM devices is done by
os_vtpm image property or the
os:vtpm flavor extra spec to
required. Other possible values are:
flavor extra spec value overrides the image property value.
The image property
os_vtpm_keys contains a comma separated UUID list,
which are references to the Barbican stored secrets. Maximum 6 references can
be added, due to nova InstanceSystemMetadata model’s limitation to 255 bytes.
Those secrets contains data that must be set into the vTPM. This is mandatory
for Shielded VMs. Providing this image property without requesting a vTPM
device will result in an exception. If one of the Barbican secrets cannot be
fetched, an exception will be raised.
Scheduling is assured by the ImagePropertiesFilter , which checks if the
hypervisor_version_requires is satisfied by the given
hosts. This is the initial approach to solving the scheduling problem. Ideally,
this problem will be solved by exposing this feature as a host capability and
os_vtpm_device image property or
os:vtpm_device flavor extra
spec match the host capability.
The following operations are to be implemented:
Add Barbican authentication config options.
Fetch the vTPM keys from Barbican using python-barbicanclient and the image property
os_vtpm_keys, which is a comma separated UUID list, which are references to Barbican secrets.
Create Host Guardian Service KeyProtector with the previously fetched encyption key and register it in the Host Guardian, if the image property
Add vTMP device to the Generation 2 VM, enable it and add the previously created KeyProtector to it.
Data model impact¶
REST API impact¶
Users will be able to use vTPM, which is useful to control access control and authentication. This can lead to enhanced VM security.
The VM encryption keys must be protected. They will have to be stored in Barbican as secrets, and make sure that the service is properly set up. For more information, see the References section .
Other end user impact¶
Other deployer impact¶
In order for this feature to be usable, the Host Guardian Service will have to be enabled and the hosts must be Guarded (the Guardian Service key must be imported in the local host). 
Barbican is needed, in order to properly use this feature . It will be used to store the VM encryption keys as secrets. In order to be able to use it, config options regarding Barbican authentication will have to be set in the compute node’s nova.conf file, under the [barbican] section. A sample will be provided. (WIP)
VMs with vTPMs cannot be migrated from an Active Directory to another or to an Unguarded Host. In order to ensure that the scheduler will not pick a host outside the current Active Directory, all the Guarded Hosts in the Active Directory should be added to the same aggregate.
This feature is only available in Windows / Hyper-V Server Technical Preview
and in order to ensure proper scheduling, the
image property should be set to
The images must be prepared for Shielded VMs. For example, the VM on which the image is prepared, it must be Generation 2 VM, have a vTPM device with a Host Guardian Service KeyProtector set. The attached drives must be encrypted using BitLocker or any encryption program . Then, the key data must be stored into Barbican as a secret. 
In order to create instances with vTPM device attached, the user will have to request it in the following ways:
optionaland flavor extra spec
Contradicting image property and flavor extra spec will result in failing to create instance.
Any key data should be stored into Barbican as secrets and create the image
os_vtpm_keys containing the comma separated references to the
secrets (maximum 6 references, due to a length limitation - maximum 255
characters), otherwise the instances will be spawned with no data stored in the
vTPMs. Example value: UUID1,UUID2,UUID3
os_vtpm_keys image property is set, the image property
os_vtpm or the flavor extra spec
os:vtpm must be set to
otherwise the instance will not spawn.
Image creation example:
- glance image-create –property hypervisor_type=hyperv
–property hw_machine_type=hyperv-gen2 –property hypervisor_version_requires=’>=10.0’ –property os_vtpm=required –property os_vtpm_keys=$key_refs –name im-secure –disk-format vhd –container-format bare –file path/to/image.vhdx
glance image-update –property hw_machine_type=hyperv-gen2 win-secure
glance image-update –property hypervisor_version_requires=’>=10.0’ im-secure
glance image-update –property os_vtpm=required im-secure
glance image-update –property os_vtpm_keys=$key_refs im-secure
os_vtpm image property acceptable values are:
disabled, optional, required. If the property is not defined,
will be used as default value. The
optional value means that the image
guest OS can use the vTPM, but it will require the flavor extra spec in order
for the instance to be created with a vTPM device.
Flavor extra spec example:
nova flavor-key m1.your.flavor set “os:vtpm=required”
- Primary assignee:
Claudiu Belu <email@example.com>
As described in the Proposed Change section.
- Hyper-V VM Generation 2 nova spec. Feature merged in Kilo.
Feature will be tested by Hyper-V CI.
New image property and flavor extra spec will have to be documented. New Barbican credentials config options will have to be documented.
-  Trusted Platform Module Technology Overview
-  Shielded VMs and Guarded Fabric Validation Guide:
-  Harden the Fabric: Protecting Tenant Secrets in Hyper-V
-  Barbican storing secrets: