Regardless of which key provider you use, with vSphere Virtual Machine Encryption you can create encrypted virtual machines and encrypt existing virtual machines. Because all virtual machine files with sensitive information are encrypted, the virtual machine is protected. Only administrators with encryption privileges can perform encryption and decryption tasks.

Important: ESXi Shell users also have cryptographic operation privileges. For more information, see Prerequisites and Required Privileges for Virtual Machine Encryption Tasks.

What Storage Does vSphere Virtual Machine Encryption Support

vSphere Virtual Machine Encryption works with any supported storage type (NFS, iSCSI, Fibre Channel, direct-attached storage, and so on), including VMware vSAN. For more information about using encryption on a vSAN cluster, see the Administering VMware vSAN documentation.

vSphere Virtual Machine Encryption and vSAN use the same encryption libraries but they have different profiles. Virtual Machine Encryption is a per-VM encryption and vSAN is a datastore level encryption.

vSphere Encryption Keys and Key Providers

vSphere uses two levels of encryption in the form of a Key Encryption Key (KEK) and a Data Encryption Key (DEK). Briefly, an ESXi host generates a DEK to encrypt virtual machines and disks. The KEK is provided by a key server, and encrypts (or "wraps") the DEK. The KEK encrypts the DEK using the AES256 algorithm and the DEK encrypts the VMDK using the XTS-AES-256 (512-bit key size) algorithm. Depending on the type of key provider, different methods are used to create and manage the DEK and KEK.

Standard key provider operates as follows.
  1. The ESXi host generates and uses internal keys to encrypt virtual machines and disks. These keys are used as DEKs.
  2. vCenter Server requests keys from the key server (KMS). These keys are used as the KEKs. vCenter Server stores only the ID of each KEK, but not the key itself.
  3. ESXi uses the KEK to encrypt the internal keys, and stores the encrypted internal key on disk. ESXi does not store the KEK on disk. If a host reboots, vCenter Server requests the KEK with the corresponding ID from the key server and makes it available to ESXi. ESXi can then decrypt the internal keys as needed.

vSphere Trust Authority trusted key provider operates as follows.

  1. 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.
  2. The vCenter Server of the Trusted Cluster adds the trusted key provider to the virtual machine ConfigSpec.
  3. The virtual machine creation request is sent to the ESXi host.
  4. If an attestation token is not already available to the ESXi host, it requests one from the Attestation Service.
  5. The Key Provider Service validates the attestation token and creates a KEK to be sent to the 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.
  6. The ESXi host generates a DEK to encrypt the virtual machine disks.
  7. 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.
  8. The virtual machine is encrypted and written to storage.
Note:

The ESXi hosts in vSphere clusters hold the KEK for encrypted virtual machines in host memory to enable availability features such as High Availability, vMotion, DRS, and so on. When a virtual machine is deleted or unregistered, the ESXi hosts in the cluster delete the KEK from their memory. Thus, the ESXi hosts can no longer use the KEK. This behavior is the same for standard key providers and trusted key providers.

vSphere Native Key Provider operates as follows.

  1. When you create the key provider, vCenter Server generates a primary key and pushes it to the ESXi hosts in the cluster. (No external key server is involved.)
  2. The ESXi hosts generate a DEK on demand.
  3. When you perform an encryption activity, data is encrypted with the DEK.

    Encrypted DEKs are stored alongside the encrypted data.

  4. When you decrypt data, the primary key is used to decrypt the DEK, and then the data.

What Components Does vSphere Virtual Machine Encryption Encrypt

vSphere Virtual Machine Encryption supports encryption of virtual machine files, virtual disk files, and core dump files.
Virtual machine files
Most virtual machine files, in particular, guest data that is not stored in the VMDK file, are encrypted. This set of files includes but is not limited to the NVRAM, VSWP, and VMSN files. The key from the key provider unlocks an encrypted bundle in the VMX file that contains internal keys and other secrets. The key retrieval works as follows, depending on the key provider:
  • Standard key provider: vCenter Server manages the keys from the key server and the ESXi hosts cannot directly access the key provider. The hosts wait for vCenter Server to push the keys.
  • Trusted key provider and vSphere Native Key Provider: The ESXi hosts directly access the key providers, and so fetch the requested keys either from the vSphere Trust Authority service directly or the vSphere Native Key Provider.
When you use the vSphere Client to create an encrypted virtual machine, you can encrypt and decrypt virtual disks separate from virtual machine files. All virtual disks are encrypted by default. For other encryption tasks, such as encrypting an existing virtual machine, you can encrypt and decrypt virtual disks separate from virtual machine files.
Note: You cannot associate an encrypted virtual disk with a virtual machine that is not encrypted.
Virtual disk files
Data in an encrypted virtual disk (VMDK) file is never written in cleartext to storage or physical disk, and is never transmitted over the network in cleartext. The VMDK descriptor file is mostly cleartext, but contains a key ID for the KEK and the internal key (DEK) in the encrypted bundle.
You can use the vSphere Client or the vSphere API to perform a shallow recrypt operation with a new KEK, or use the vSphere API to perform a deep recrypt operation with a new internal key.
Core dumps
Core dumps on an ESXi host that has encryption mode enabled are always encrypted. See vSphere Virtual Machine Encryption and Core Dumps. Core dumps on the vCenter Server system are not encrypted. Protect access to the vCenter Server system.
Virtual machine swap file
The virtual machine swap file is encrypted whenever you add a vTPM to a virtual machine. Environments low on RAM can experience encryption-related paging that could impact performance.
vTPMs
When you configure a vTPM, the virtual machine files are encrypted but not the disks. You can choose to add encryption explicitly for the virtual machine and its disks. For more information, see Securing Virtual Machines with Virtual Trusted Platform Module.
Note: For information on some limitations concerning devices and features that vSphere Virtual Machine Encryption can interoperate with, see Virtual Machine Encryption Interoperability.

What Components Does vSphere Virtual Machine Encryption Not Encrypt

Some of the files that are associated with a virtual machine are not encrypted or partially encrypted.
Log files
Log files are not encrypted because they do not contain sensitive data.
Virtual machine configuration files
Most of the virtual machine configuration information, stored in the VMX and VMSD files, is not encrypted.
Virtual disk descriptor file
To support disk management without a key, most of the virtual disk descriptor file is not encrypted.

What Privileges Are Required to Perform Cryptographic Operations

Only users that are assigned the Cryptographic Operations privileges can perform cryptographic operations. The privilege set is fine grained. The default Administrator system role includes all Cryptographic Operations privileges. The No Cryptography Administrator role supports all Administrator privileges except for the Cryptographic Operations privileges.

In addition to using the Cryptographer.* privileges, vSphere Native Key Provider can use the Cryptographer.ReadKeyServersInfo privilege, which is specific to vSphere Native Key Providers.

See Cryptographic Operations Privileges for more information.

You can create additional custom roles, for example, to allow a group of users to encrypt virtual machines but to prevent them from decrypting virtual machines.

How Do You Perform Cryptographic Operations

The vSphere Client supports many of the cryptographic operations. For other tasks, you can use PowerCLI or the vSphere API.

Table 1. Interfaces for Performing Cryptographic Operations
Interface Operations Information
vSphere Client Create encrypted virtual machine

Encrypt and decrypt virtual machines

Perform a shallow recrypt of a virtual machine (use a different KEK)

 This book
PowerCLI Create encrypted virtual machine

Encrypt and decrypt virtual machines

Configure vSphere Trust Authority

 VMware PowerCLI Cmdlets Reference
vSphere Web Services SDK Create encrypted virtual machine

Encrypt and decrypt virtual machines

Perform a deep recrypt of a virtual machine (use a different DEK)

Perform a shallow recrypt of a virtual machine (use a different KEK)

 vSphere Web Services SDK Programming Guide

vSphere Web Services API Reference

crypto-util Decrypt encrypted core dumps

Check whether files are encrypted

Perform other management tasks directly on the ESXi host

 Command-line help

vSphere Virtual Machine Encryption and Core Dumps

How Do You Recrypt (Rekey) an Encrypted Virtual Machine

You can recrypt (also called rekey) a virtual machine with new keys, for example, in case a key expires or becomes compromised. The following rekeying options are available.

  • A shallow recrypt, which replaces only the Key Encryption Key (KEK)
  • A deep recrypt, which replaces both the Disk Encryption Key (DEK) and the KEK

A deep recrypt requires that the virtual machine is powered off and contains no snapshots. You can perform a shallow recrypt operation while the virtual machine is powered on, and if the virtual machine has snapshots present. Shallow recrypt of an encrypted virtual machine with snapshots is permitted only on a single snapshot branch (disk chain). Multiple snapshot branches are not supported. Also, shallow recrypt is not supported on a linked clone of a virtual machine or disk. If the shallow recrypt fails before updating all links in the chain with the new KEK, you can still access the encrypted virtual machine if you have the old and new KEKs. However, it is best to reissue the shallow recrypt operation before performing any snapshot operations.

You can perform a rekey of a virtual machine by using the vSphere Client, the CLI, or the API. See Rekey an Encrypted Virtual Machine Using the vSphere Client, Rekey an Encrypted Virtual Machine Using the CLI, and vSphere Web Services SDK Programming Guide.