Azure provides multiple types of Disk Encryption options. But apart from their features (when you can use which one), lets dive into the how they actually work and differentiate from each other. So this post, in line with Azure for Sovereignty goes into the disk encryption options for Virtual Machines.

We have four options for encryption (specifically with Customer Managed Keys) for Virtual Machine disks.

1. Azure Disk Storage Server-Side Encryption
2. Encryption at Host
3. Azure Disk Encryption
4. Confidential Disk Encryption

1. Azure Disk Storage Server-Side Encryption

Server-Side Encryption always means that the server or controller of the service will encrypt/decrypt on behalf of other services. While the stored or processed data is encrypted at rest, the data is given transparently to the using service, and for Disk Encryption it is exactly the same.

A disk (file) is stored on external storage (Azure Storage). The stored disk is tagged with a Disk Encryption Set, that holds the pointers to the encryption keys. The encryption architecture uses the same principle as other Azure services, Envelope encryption. Hence, the Data Encryption Key of the actual disk (file) is protected (encrypted) by a Key Encryption Key public key. In order to get to the Data Encryption Key, the storage controllers will use the Managed Identity on the Disk Encryption Set (configuration file) to connect to the key Vault (or Managed HSM) to get the actual Data Encryption Key (DEK). That DEK is loaded into the storage memory controller, the disk (file) is unlocked and provided to the VMM HOST which in turn mounts the disk to the actual VM.

While all communication channels are protected with TLS, note that the DEK itself is loaded into the storage controllers (in unencrypted format) that provide the disk (file) to the VMM host.

2. Encryption at Host

Within the Host Encryption architecture, the VMM host itself is responsible for decrypting the disks prior to giving it to the VM.

The encrypted disk (file) is loaded by the VMM host. As the disk is again protected by an actual Data Encryption Key (DEK) which is wrapped with a (public) Key Encryption Key. In order to get to the actual DEK, the Host itself will use the configured managed Identity to access the vault, giving it the wrapped DEK to be unwrapped by the Private Key Encryption key in the vault. The “unencrypted” DEK is returned to the host which uses that to unlock the disk prior to providing it to the VM.

3. Azure Disk Encryption

While options 1 and 2 rely on external encryption of the disk file (.vhd), the Azure Disk Encryption and Confidential Disk Encryption uses volume encryption technologies. That means that the file itself isn’t encrypted (outside of the standard Azure fabric encryption), but the volumes containing the customer files are actually encrypted using BitLocker or DM-Crypt. It is the VM itself that unlocks the disk at boot. For this, an extension is used within the VM to process the unlocking of the disk. At boot time the extension uses the Identity of the VM (system or User) to access KeyVault to retrieve the Bitlocker Encryption Key which was stored when the encryption was enabled (2). The architecture of BitLocker uses a similar envelope encryption where the volume encryption key (VEK) is protected by the BitLocker Encryption Key (BEK). KeyVault will upon successful authentication return the BEK to the VM (3) so it can extract the VEK and unlock the disk.

Note that in this case, the BEK is hosted in the VM memory space and is stored in KeyVault. Given the architecture stores a BitLocker Encryption Key and does not use a KeyPair with unwrap methods, Managed HSM cannot be used.

4. Confidential Disk Encryption

BitLocker can be unlocked using the BEK, but BitLocker can also be configured to use an external (protector) encryption key. In short, the Volume Encryption Key is itself encrypted using a public key of a key pair (where the private key is stored externally). Usually used in combination with smartcards or BitLocker network unlock, the Confidential Azure Disk Extension can also use a key stored in Managed HSM or KeyVault Premium as the Bitlocker external key protector. In this case, the private key used needs to be released from the vault to the VM, so it can use the private key to unlock BitLocker of the Operating System Disk and allow the VM to boot.

For the release of the private key, Managed HSM and Key Vault Premium have something called Secure Key Release. When a key is created with a specific “exportable” policy, the key is marked in the HSM that the private key itself can be released under specific conditions. In short, explicitly marked keys can be sent to the requestor if the request meets a few criteria:

1. Explicit permissions are granted to the identity to export the key
2. The key is marked as exportable
3. The request matches the release policy of the key

Under normal circumstances, a user defined policy will indicate that the key can only be released if Azure Confidential Computing is used. This policy is written in JSON format and for example states:

"claim":  "x-ms-isolation-tee.x-ms-attestation-type",
"equals":  "sevsnpvm"

But other options are valid as well, and it is up to the key creator to provide a more loosely or stricter policy when creating the key (version).

When the VM is allocated (1) the VMM Host passes the encrypted disk to the VM. The VM calls the external attestation service (2) to get a full report on its Trusted Execution Environment – the attestation report (3). This report is then sent to the key vault in a secure key release call (4). If the attestation report (identity, permissions, and key properties) match, the vault will release the private key of the Key Encryption Key to the VM (5). The VM itself than uses the private key to unlock the Volume Encryption Key of BitLocker (or DM-Crypt) and mounts the disk prior to booting.

Note that in this architecture, the Private Key is actually released over an SSL channel established by the TEE itself. That means, that even the VMM host operator cannot see the private key, only the TEE can decrypt it. That means that all aspects of the unlock / decryption process is handled in a confidential manner.

Worthy to note is that Confidential Disk Encryption (today) is only available for Operating System disks. Data drives cannot use CDE at the moment. However, it is possible to use BitLocker or DM-Crypt inside the VM itself (with auto-unlock) for data drives. This will store the BEK for those disks in the virtual TPM which is stored with the VM itself in an encrypted (protected) format. However, make sure to write-down the recovery keys or ensure the recovery keys are stored in Active Directory (for BitLocker) to avoid losing access to data in emergencies.

Summary

To summarize the options:

	Server Side	At Host	Disk Encryption	Confidential DE
Encryption At Rest	V	V	V	V
Temp disk encryption	X	V	V	V(preview)
Encryption of caches	X	V	V	V
Data flows encrypted between Compute and Storage	X	V	V	V
Customer control of keys	V ICW DES	V ICW DES	V ICW DES	V ICW DES
HSM Support	KV Premium / M-HSM	KV Premium / M-HSM	KV Premium	KV Premium / M-HSM
Does not use your VM’s CPU	V	V	X	X
Works for custom images	V	V	X (Linux)	V
Enhanced Key Protection	X	X	X	V (OS disk only)