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 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 Administering VMware vSAN documentation.

vSphere Virtual Machine Encryption and vSAN use the same encryption libraries but they have different profiles. VM 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: If you delete or unregister an encrypted virtual machine, the ESXi host and the cluster remove the KEK from cache. The ESXi host 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 Is Encrypted

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 are 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 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 API to perform either a shallow recrypt operation with a new KEK or 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.
Note: For information on some limitations concerning devices and features that vSphere Virtual Machine Encryption can interoperate with, see Virtual Machine Encryption Interoperability.

What Is Not Encrypted

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.

Who Can 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 Can I Perform Cryptographic Operations

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

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

Encrypt and decrypt virtual machines

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

Recrypting Virtual Machines

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

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

You must perform a recrypt of a virtual machine by using the API. See vSphere Web Services SDK Programming Guide.

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.