Understanding vSphere Trust Authority process flows is essential to learning how to configure and administer your Trusted Infrastructure.
Enabling vSphere Trust Authority
vSphere Trust Authority is not enabled by default. You must manually configure vSphere Trust Authority in your environment. See Configuring vSphere Trust Authority in Your vSphere Environment.
When you enable vSphere Trust Authority, you must specify which versions of ESXi software the Attestation Service accepts, and also which Trusted Platform Modules (TPMs) are trustworthy.
TPM and Attestation
This guide uses the following definitions when discussing TPMs and attestation.
|Endorsement Key (EK)||A TPM is manufactured with an RSA public/private key pair built into the hardware, called the endorsement key (EK). The EK is unique to a particular TPM.|
|EK Public Key||The public portion of the EK key pair.|
|EK Private Key||The private portion of the EK key pair.|
|EK Certificate||The EK public key wrapped with a signature. The EK certificate is created by the TPM manufacturer who uses its Certificate Authority private key to sign the EK public key. Not all TPMs contain an EK certificate. In this case, the EK public key is not signed.|
|TPM Attestation||The ability of the Attestation Service to verify the software that is running on a remote host. TPM attestation is accomplished through cryptographic measurements made by the TPM while the remote host starts, and is relayed to the Attestation Service on request. The Attestation Service establishes trust in the TPM through either the EK public key or the EK certificate.|
Configuring TPM Trust on the Trusted Hosts
An ESXi Trusted Host must contain a TPM. A TPM is manufactured with a public/private key pair built into the hardware, called the endorsement key (EK). Although TPM 2.0 permits many key/certificate pairs, the most common is an RSA-2048 key pair. When a TPM EK public key is signed by a CA, the result is the EK certificate. The TPM manufacturer typically pre-generates at least one EK, signs the public key with a Certificate Authority, and embeds the signed certificate in the TPM's non-volatile memory.
You can configure the Attestation Service to trust TPMs as follows:
- Trust all CA certificates with which the manufacturer signed the TPM (the EK public key). The default setting for the Attestation Service is to trust CA certificates. In this approach, the same CA certificate covers many ESXi hosts, and so reduces your administrative overhead.
- Trust the ESXi host's TPM CA certificate and EK public key. The latter can be either the EK certificate or the EK public key. Although this approach provides more security, it requires you to configure information about each Trusted Host.
- Some TPMs do not contain an EK certificate. In this case, you trust the EK public key.
Deciding to trust all TPM CA certificates is operationally convenient. You configure new certificates only when you add a new class of hardware to your data center. By trusting individual EK certificates, you can limit access to specific ESXi hosts.
You can also decide not to trust TPM CA certificates. Though an uncommon situation, you can use this configuration when an EK is not signed by a CA. Currently, this functionality is not fully implemented.
To begin the attestation process, the ESXi Trusted Host in the Trusted Cluster sends the pre-configured EK public key and EK certificate to the Attestation Service on the Trust Authority Cluster. When the Attestation Service receives the request, it looks up the EK in its configuration, which can be the EK public key or the EK certificate, or both, depending on the configuration. If no case is valid, the Attestation Service rejects the attestation request.
The EK is not directly used for signing, so an Attestation Key (AK or AIK) is negotiated. The negotiation protocol ensures that a newly created AK is bound to the previously verified EK, preventing a man-in-the-middle situation, or an impersonator. After an AK is negotiated, it is reused on future attestation requests rather than generating a new one each time.
The ESXi Trusted Host reads the Quote and PCR values from the TPM. The Quote is signed by the AK. The ESXi Trusted Host also reads the TCG Event Log, which includes all the events that resulted in the current PCR state. This TPM information is sent to the Attestation Service for validation. The Attestation Service verifies the PCR values using the event log.
Key Providers and Key Servers
The Key Provider Service uses the concept of a trusted key provider to hide the key server specifics from the rest of the data center software. Each trusted key provider has a single configured primary encryption key (previously called a master encryption key), and references one or more key servers. The primary encryption key is present in the key servers. As part of configuring vSphere Trust Authority, you must provision the primary key (previously called a master key) as a separate activity and activate it. The Key Provider Service can have several configured trusted key providers. Each trusted key provider uses a different primary key, but can reference the same backing key server.
When a new trusted key provider is added, the Trust Authority administrator must specify the key server and an existing key identifier on that key server.
The following figure shows the relationship between the Key Provider Service and key servers.
After you configure a trusted key provider for a Trusted Cluster, the Key Provider Service can accept requests to run cryptographic operations against that trusted key provider. For example, in this figure, three trusted key providers are configured, two for KMS-1, and one for KMS-2. The Trusted Host requests an encryption operation against key-provider-2. The Trusted Host requests an encryption key to be generated and returned, and uses this encryption key to perform encryption operations.
The Key Provider Service uses the primary key referenced by key-provider-2 to encrypt the specified plaintext data and return the corresponding ciphertext. Later, the Trusted Host can provide the same ciphertext to a decrypt operation and get back the original plaintext.
Authentication and Authorization
vSphere Trust Authority administrative operations require a user that is a member of the TrustedAdmins group. Having only Trust Authority administrator privileges is not sufficient to perform all administrative operations that involve the ESXi hosts. For more information, see Prerequisites and Required Privileges for vSphere Trust Authority.
Adding a Trusted Host to a Trusted Cluster
The steps to add ESXi hosts initially to the Trusted Cluster are described in Configuring vSphere Trust Authority in Your vSphere Environment.
Later, if you want to add ESXi hosts to the Trusted Cluster, the workflow is different. See Adding and Removing vSphere Trust Authority Hosts.
When you initially add ESXi hosts to the Trusted Cluster, you must gather the following information:
- TPM certificate for each type of hardware in the cluster
- ESXi image for each version of ESXi in the cluster
- vCenter Server principal information
If you later add ESXi hosts to a Trusted Cluster, you might need to collect some additional information. That is, if the new ESXi hosts differ in hardware or ESXi version from the original hosts, you must collect the new ESXi host information and import it to the Trust Authority Cluster. You only must collect the vCenter Server principal information one time per vCenter Server system.
vSphere Trust Authority Encryption Process Flow
The vSphere Trust Authority encryption process flow includes the vSphere Trust Authority services, the trusted key providers, the vCenter Server, and the ESXi hosts.
Encrypting a virtual machine with a trusted key provider looks the same as the virtual machine encryption user experience that was first delivered in vSphere 6.5. Virtual machine encryption under vSphere Trust Authority continues to rely on either virtual machine encryption storage policies, or the presence of a vTPM device, to decide when to encrypt a virtual machine. You still use a default configured key provider (called a KMS in vSphere 6.5 and 6.7) when encrypting a virtual machine from the vSphere Client. And, you can still use the APIs in a similar way to specify the key provider manually. The existing Cryptographic privileges added for vSphere 6.5 are still relevant in vSphere 7.0 for vSphere Trust Authority.
The encryption process in vSphere Trust Authority has some important differences:
Trust Authority administrators do not specify information directly when setting up a key server for a vCenter Server instance, and they do not establish the key server trust. Instead, vSphere Trust Authority publishes trusted key providers that the Trusted Hosts can use.
- vCenter Server no longer pushes keys to ESXi hosts and instead it can treat each trusted key provider as a single top-level key.
- Only Trusted Hosts can request encryption operations from Trust Authority Hosts.
When a user performs an encryption task using vSphere Trust Authority, such as creating an encrypted virtual machine, different components interact as follows:
- The vCenter Server of the Trusted Cluster checks if the default trusted key provider is accessible to the ESXi host where the encrypted virtual machine is to be created.
- The vCenter Server of the Trusted Cluster adds the trusted key provider to the virtual machine ConfigSpec.
- The virtual machine creation request is sent to the ESXi host.
- If an attestation token is not already available to the ESXi host, it requests one from the Attestation Service.
- The Key Provider Service validates the attestation token and creates a Key Encryption Key (KEK) to be sent to ESXi host. The KEK is wrapped (encrypted) with the primary key that is configured on the key provider. Both the KEK ciphertext and KEK plaintext are returned to the Trusted Host.
- The ESXi host generates a Data Encryption Key (DEK) to encrypt the virtual machine disks.
- The KEK is used to wrap the DEK generated by the ESXi host, and the ciphertext from the key provider is stored alongside the encrypted data.
- The virtual machine is encrypted and written to storage.