Understanding vSphere Trust Authority process flows is essential to learning how to configure and manage your Trusted Infrastructure.
How Do You Configure vSphere Trust Authority
vSphere Trust Authority is not activated by default. You must manually configure vSphere Trust Authority in your environment. See Configuring vSphere Trust Authority.
When you configure 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.
| Term | Definition |
|---|---|
| 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.
Attesting TPMs
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.
How Do Key Providers Work with 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, 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 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.
vSphere Trust Authority 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.
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.
