About Virtual Trusted Platform Module

A Virtual Trusted Platform Module (vTPM) is a software-based representation of a physical Trusted Platform Module (TPM) 2.0 chip. With the vTPM feature, you can add a TPM 2.0 virtual cryptoprocessor to a virtual machine. Google Cloud VMware Engine supports vTPMs.

You can use the Default Key Provider, Cloud Key Management Service, or an external KMS to create vTPMs. Google recommends that you configure the key provider as the default key provider in vCenter before you create a vTPM.

Adding vTPMs to VMs

You can add vTPMs to VMs by adding the "Trusted Platform Module" virtual device to the VM. See vSphere Virtual TPM (vTPM) Questions & Answers for more information.

vTPM and VM encryption for workload VMs

Workload VMs use an internal seed stored within the virtual Trusted Platform Module (vTPM) to encrypt workload data. When you add a vTPM, the system encrypts the VM home files by default but doesn't include the virtual machine disks (VMDKs). To encrypt the VMDKs, you must encrypt them separately.

Data storage and prerequisites

The system stores vTPM data in the NVRAM file in the VM's home directory, along with other VM metadata. To use vTPM, you must meet the following requirement:

  • Configure a key provider: You must configure a key provider because vTPM functionality requires VM encryption. VM encryption protects the vTPM data in the VM's home directory.

Key considerations for re-keying VMs with vTPM

Re-keying a VM with a vTPM device updates only the encryption key that protects the vTPM data in the VM's home directory. You can't change the seed within a vTPM after instantiation.

  • When you add a vTPM device to a VM, the device generates an internal seed. Applications running on the guest operating system can use this seed to generate secrets or encryption keys to protect application data.
  • Separately, enabling vTPM on a VM requires VM file encryption that uses an external key provider. VMDK encryption is optional and disabled by default.
  • The encryption key from the external key provider encrypts the VM files (and the VMDKs, if you enabled encryption). This key is separate from the seed stored in the vTPM device or the keys that applications generate by using that seed.
  • You must configure the external key provider as the default key provider in vCenter.
  • Re-encrypting a VM with a vTPM device re-encrypts VM files (and VMDKs, if you enabled encryption) by using a new encryption key from the external key provider. This operation doesn't affect the seed or secrets stored in the vTPM device.

Requirement for encrypted virtual machines

You can manage encryption keys for VMs by using the default Google-owned and managed key provider or Cloud Key Management Service.

If you enable VM Encryption (or vTPM) for any VMs in your private cloud and use a KMS to manage encryption keys, you must re-encrypt (shallow re-key) each VM after you rotate your KMS key.

A shallow re-key replaces only the key encryption key (KEK) and doesn't change the data encryption key (DEK) of the VMs. You typically trigger a shallow re-key by using the Re-encrypt action in the vSphere Client.

During this operation, the system re-wraps (re-encrypts) the existing DEK by using a new KEK. This process is fast because it doesn't rewrite actual data on the disk; instead, it only updates the small key bundle that contains the encrypted DEK. For more information, see the following VMware documentation:

Risks of failing to re-key encrypted VMs

Failing to re-key encrypted VMs before you delete the rotated (old) KMS key version can cause the following issues:

  • Failed vMotions: ESXi hosts can't decrypt VM DEKs during vMotion if you reboot the destination hosts or add them to the cluster after the KMS key rotation but before you perform the VM re-key.
  • Power-on failures: If a host reboots or clears its local key cache, it can't reacquire keys from the KMS. If you deleted the required keys from the KMS, the host can't decrypt the DEK, which prevents encrypted VMs from powering on.

Steps to perform a re-key operation on workload VMs

  1. In the vSphere Client, right-click the VM.
  2. Select VM Policies > Re-encrypt.
  3. Confirm the re-encryption request in the dialog that appears.
  4. Wait for the task to complete.
  5. Verify the re-key by migrating the VM to a host that you rebooted or added to the cluster after the KMS key rotation.