As security becomes a bigger and bigger “thing”, requirements for virtualized hardware to support features in guest operating systems are rising. With vSphere 6.7 we have released a comprehensive list of virtual hardware support for features required by Windows 10 and Windows 2016. In a previous blog we covered support for Virtualization Based Security (VBS) and briefly covered virtual TPM.
In this blog article we will go deeper on the new feature for Windows 10 and 2016 guests called “Virtual TPM”.
What is a virtual TPM?
A vTPM, or “virtual Trusted Platform Module 2.0”, performs the same functions as a physical TPM 2.0 device, but it performs cryptographic coprocessor capabilities in software. Learn more about TPM’s at the Trusted Computing Group website.
Virtual TPM for Guests
Requirements
There are some requirements necessary in order to add a virtual TPM to a Windows 10 or 2016 VM
- Be at Virtual Machine Hardware Version 14
- Use EFI firmware
- Have VM Encryption configured in vCenter.
Use of a vTPM
The specific use case for a vTPM on vSphere is to support Windows 10 and 2016 security features. The HTML5 UI is designed with this in mind. Enablement of VBS does not require a vTPM.
Enablement of vTPM for any VM other than Windows 10 and 2016 is done via API. More on that in the future.
Let’s get a question I get asked about out of the way up front.
“Does this mean I can run Bitlocker on a Windows VM now?!”
Well, technically, all the parts are now there to run Bitlocker but I have to ask “Why??”. Remember, in order to enable vTPM you have to already have VM Encryption!
This means you already have a virtual machine encryption solution that’s easy to manage and works for every virtual machine that’s supported on vSphere, regardless of the guest operating system. Not to mention, you don’t have to manage the encryption “in guest” which lowers your overall workload significantly. #NoSecuritySnowflakes
Adding a vTPM
Adding a virtual TPM is as simple as adding a new virtual device to a VM.
You can only do this task if a Key Manager is configured in vCenter.
When the vTPM is added the VM’s “home” files will be encrypted. See below.
vTPM Uniqueness
A hardware based TPM is provisioned with a unique Endorsement Key (EK) “at the factory”. The EK has a private and public key. These keys are preloaded into the chip and are generated by the vendors Certificate Authority (CA).
When the vTPM device is added an Endorsement Key Certificate is issued by VMCA. This is used to provide the vTPM with its unique identity. The key pair used to provide the unique identity to the vTPM lives with the vTPM. Once the vTPM uses a key, it is typically not changed because doing so invalidates sensitive information stored in the vTPM.
While the key pair is part of a digital certificate issued either by the VMware Certificate Authority (VMCA) or by a third-party Certificate Authority (CA).
The vTPM does not contact the CA at any time.
This is analogous to a physical TPM. A physical TPM has no method by which it can contact the TPM vendor’s CA. You can verify the digital certificate used by the TPM, just like on physical, if you so choose.
Replacement of VMCA issued certificates with a set of certificates from your own Certificate Authority is done via the HTML5 UI. See the image below:
The ability is there to do these operations via API. I’ll cover that in a future blog.
Securing a virtual TPM
A hardware TPM has the ability to store information securely in what’s referred to as “Non-Volatile Secure Storage”. On a physical TPM this is a hardware-based component of the TPM device itself. It is part of a tamper resistant integrated circuit.
See the image below that is a representation of the contents of a TPM based on information from the Trusted Computing Group
You can see that there is a limited storage area for items like credentials or certificates and another for secure storage of “Platform Configuration Registers”. This allows for storage and reporting of security relevant metrics. These storage areas are measured in kilobytes.
A virtual TPM doesn’t have a hardware based component so instead, when the data to be secured is written to the “Non-Volatile Secure Storage” by the guest OS it is actually written (via in-guest TPM 2.0 API’s) to the “.nvram” file which is encrypted using VM Encryption.
This provides for a software controlled, “tamper resistant” storage of data. It’s “tamper resistant” because it’s encrypted with VM Encryption. This software control does not live in the VM. It’s part of the virtual device presented to the VM and it is controlled by the ESXi hypervisor.
Operational Benefits
From an IT and Security operations standpoint the use of the described virtual TPM provides a number of key features and benefits.:
- Data written to the vTPM is secured with very strong encryption. (AES-XTS-256)
- Any data written to the vTPM by the guest OS will be stored in the .nvram file.
- Because we use VM Encryption, we retain the portability of virtual machines.
- You can vMotion a virtual machine with a vTPM for example.
- Because the VM is encrypted, the predefined “No Cryptography Administrator” role can now be used to restrict management permissions of the VM. Use of this role puts a number of restrictions on the management of the VM itself:
- No console access in the vSphere Client
- Prevents downloads of the VM from the datastore via the datastore browser
- No ability to remove the vTPM from the VM
- Enforces a “least privilege” operational mode
Encryption is only performed on the VM “Home” files and not the VMDK’s unless you choose to encrypt the VMDK’s. Therefore, impact to performance is minimal as we are only encrypting a few files on the datastore.
The “home” files that are encrypted are
- The .nvram file
- Parts of the VMX file
- Swap, log, .vmss, .vmsn, namespacedb
- DeployPackage (used by Guest Customization)
Why not use the physical TPM on the host?
The vTPM is not dependent on the physical TPM. It does not “chain” to the physical TPM nor is its storage backed by the physical TPM. To do so would introduce a number of operational issues. Let’s explore some of the capabilities of a physical TPM and why we chose not to use it for VM’s.
- A physical TPM is not designed for 100’s or 1000’s of VM’s to store their credentials. The “Non-Volatile Secure Storage” is measured in kilobytes!
- A physical TPM is a device sitting on the “Low Pin Count” bus. This is the same bus that legacy devices like a serial port or PS/2 mouse connect to. It is very slow.
- One of the functions of a TPM is to perform cryptographic operations. If there were 100’s of VM’s on a host and all of them wanted to call a TPM API to do a crypto operation, like signing something, then you would need a scheduler. In front of a serial device.
- Even if I could store all that data on a physical TPM, how would I move it securely to another host if I vMotion or keep hosts synchronized? In a secure manner that passes all sorts of security requirements?
As you can imagine, the challenges of using a physical TPM range from “it won’t physically work” to “Holy cow this is becoming VERY complex!”
This is one of the reasons why we designed our vTPM solution as we did. It provides operational flexibility with strong security. If you think about a disaster recovery situation the last thing you want to deal with is an inflexible security solution.
Disasters
With the dependency on VM Encryption for securing the data of the vTPM we inherit some key benefits from a disaster recovery standpoint. So long as you paid attention to my Key Manager Topology blog article and didn’t depend on a single Key Manager system you will be in good shape!
Let’s explore the scenario where your vCenter is no longer available and you have a disk array full of encrypted VM’s. Provided your KMS infrastructure is still available (again, see the blog), you can create a new vCenter, set up the trust with the KMS infrastructure and register your encrypted VM’s and power them on.
Because the .nvram file travels with the VM and the VM is “encrypted”, the data is secured. The same principles apply if you wish to move that VM to another vSphere installation. That vSphere installation must be connected via a trusted connection to the same Key Management infrastructure.
Cross vCenter vMotion of an encrypted VM is not supported. I’m talking about a cold migration of the VM in this scenario.
Backup and Restore
You can also back up a virtual machine enabled with a vTPM. The backup must include all virtual machine data, including the *.nvram file. If your backup does not include the *.nvram file, you cannot restore a virtual machine with a vTPM. Also, because the VM home files of a vTPM-enabled virtual machine are encrypted, ensure that the encryption keys are available at the time of a restore. Please work with your backup vendors to better understand their roadmap for support of encrypted virtual machines.
Operational Considerations
If you are using VM Encryption or, because of vTPM, you are now considering it, it’s time to sit down and have that “Least Privilege” conversation. If you have 10 sysadmins, all of them granted the “Administrator” role, it’s time to re-evaluate. Anyone with “Administrator” has full rights and privileges to do tasks that could potentially compromise the integrity you seek with vTPM.
Consider moving most of your administrators to the “No Cryptography Administrator” role as a good start towards least privilege management of your vSphere infrastructure. If you are a vRealize Automation customer then I encourage you to check out a VMworld session on using vRA for Least Privilege operations It’s GRC2226BU and it’s available on YouTube and the slides are available in PDF format.
Wrap Up
As I’ve pointed out before, one of the important things to remember as we add new security functionality in a virtualized datacenter is that what you do in the physical world might not work in the virtual world. Each environment presents its own unique strengths and considerations. The points of where and how you apply security shift.
As an example, with a hardware TPM you give up some amount of mobility and flexibility because you are rooted in hardware. This might be ok for a laptop as your threats there are one of securing the laptop if it is out of your control. In a virtualized world with vTPM, that security perimeter changes. The VM is always in your control. You are now rooted in the trust of the hypervisor and its components and you are using a key manager to manage tampering with secure data, but you gain (or retain!) the flexibility and mobility that virtualization brings while still retaining or enhancing your security. It’s a different set of threats.
Adoption of any new security technology must come with the willingness to review your current methods of how you use similar technology and then adapt your methods. There are huge benefits with virtualization but if you apply old rules are you truly getting the most out of your investment?
As always, you can reach me on Twitter at @vspheresecurity or @mikefoley. Those are probably the easiest and quickest ways to ask a question and get a response.
Thanks for reading,
mike
You must be logged in to post a comment.