In vSphere 7.0, when a virtual machine with a vTPM device is cloned, the secrets and identity in the vTPM are cloned as well. In vSphere 8.0 there is an option during a clone to replace the vTPM so that it gets its own secrets and identity (more information available here: Clone an Encrypted Virtual Machine (vmware.com)).
Someone recently asked me if it would be possible to programmatically find VMs that had duplicate key/secrets. I looked and found a Get-VTpm
cmdlet, which returns a VTpm Structure that contains an Id
and Key
property. I suspected that the Key
property would contain the key we were interested in, so I setup a quick test to confirm. Here is the output of a few VMs with vTPM devices showing the Id
and Key
values.
Get-VM | Get-VTpm | select Parent, Name, Id, Key
Parent Name Id Key
------ ---- -- ---
clone_unique Virtual TPM VirtualMachine-vm-1020/11000 11000
clone_dupeVtpm Virtual TPM VirtualMachine-vm-1019/11000 11000
New Virtual Machine Virtual TPM VirtualMachine-vm-1013/11000 11000
As we can see, the Key
is actually the hardware device key of 11000
which is static, regardless of whether we expect a duplicate vTPM or not.
However, digging into ExtensionData
I found some other more interesting properties, specifically EndorsementKeyCertificateSigningRequest
and EndorsementKeyCertificate
. Comparing the EndorsementKeyCertificate
property confirmed that when a vTPM is duplicated this key is the same, but when it has been replaced it is unique. Taking that information into account, this one liner would group vTPMs by duplicate keys:
Get-VM | Get-VTpm | Select-Object Parent, @{N='vTpmEndorsementKeyCertificate';E={[string][System.Text.Encoding]::Unicode.GetBytes($_.ExtensionData.EndorsementKeyCertificate[1])}} | Group-Object vTpmEndorsementKeyCertificate
The output of this command would be a grouping per key. The Group
property would contain all the VM names (aka Parent
in this context) using the same key. In the example below, there is 1 VM with a unique key and 2 VMs sharing a key.
Count Name Group
----- ---- -----
1 52 0 56 0 32 0 49 0 51... {@{Parent=clone_unique; vTpmEndorsementKeyCertificate=52 0 56 0 32 0 49 0 51 0 48 0 32 0 51 0 32 0 50 0 49 0 57 0 32 0 52 0 56 0 3...
2 52 0 56 0 32 0 49 0 51... {@{Parent=clone_dupeVtpm; vTpmEndorsementKeyCertificate=52 0 56 0 32 0 49 0 51 0 48 0 32 0 51 0 32 0 50 0 49 0 57 0 32 0 52 0 56 0...
Using this information we could remove/replace the vTPM in the duplicate VMs if needed to ensure a unique key. Note, per the documentation here, “As a best practice, ensure that your workloads no longer use a vTPM before you replace the keys. Otherwise, the workloads in the cloned virtual machine might not function correctly.”