Disk Encryption

Enclave OS Virtual encrypts all persistent data at rest using LUKS2 with authenticated encryption (AEAD). The disk has two encrypted regions with independent keys, and the encryption status is attested in every RA-TLS certificate.

Encrypted Regions

The two regions use separate keys. A compromise of one container's volume key does not expose the OS data partition or any other container's data.

OS Data Partition

The /data key is a data encryption key held as Shamir shares on the Enclave Vaults constellation — it is generated inside the enclave, never exists outside TEE memory, and nothing secret is stored in instance metadata or on the host. At boot, before the data mount:

1. On the very first boot, the machine redeems a single-use, operator-pre-approved bootstrap token with a fresh TDX quote whose measurements must match the approved Enclave OS release. It then generates the key in-enclave, splits it onto the vault constellation, and formats the partition with LUKS2+AEAD.
2. On every later boot, a non-secret locator stored in the LUKS2 header points at the constellation; the machine authenticates with a fresh TDX quote, reconstructs the key from its shares over mutual RA-TLS, and opens the volume. No human is involved.
3. The key origin ("vault:<handle>", or "byok:<fingerprint>" on legacy machines) is written to /run/luks/dek-origin and published as OID 1.3.6.1.4.1.65230.2.6 in every RA-TLS certificate.

This means a remote verifier can check the RA-TLS certificate's OID 2.6 extension and confirm how the data partition is keyed: vault-held (the default — the key is gated on the machine's attested identity) or a customer-provided key (legacy BYOK).

Per-Container Encrypted Volumes

Each container receives an independent LVM logical volume with its own LUKS2+AEAD encryption key. Keys are never shared between containers and never stored on the OS data partition. They are held only in TEE-encrypted memory at runtime.

When a container load request includes a BYOK key, the launcher:

1. Creates a new LVM logical volume on the container volumes partition.
2. Formats it with LUKS2+AEAD using the provided key.
3. Mounts it at the container's designated volume path.
4. Embeds "byok:<fingerprint>" in OID 1.3.6.1.4.1.65230.3.4 of that container's RA-TLS certificate.

When the key source is Enclave Vaults, the launcher establishes a mutual RA-TLS connection to the vault constellation, authenticates using the VM's own RA-TLS certificate, and retrieves the data encryption key. The vault verifies the VM's attestation before releasing the key, creating a mutual trust chain: the VM proves its identity to the vault, and the vault proves its identity to the VM.

LUKS2 with AEAD

LUKS2+AEAD (dm-integrity in AEAD mode) provides both confidentiality and integrity for each disk sector. Standard LUKS2 encrypts data but does not detect tampering. With AEAD, every sector carries an authentication tag that is verified on read.

This protects against:

• Offline attacks: An attacker with physical access to the disk cannot read or modify encrypted data.
• Ciphertext manipulation: Flipping bits in the ciphertext is detected on the next read, preventing subtle data corruption attacks.
• Sector-level replay: Restoring an old sector's ciphertext to its original position is detected because the authentication tag depends on the sector index and write counter.

The trade-off is that online resize is not supported. The --integrity aead mode uses dm-integrity, which cannot be grown in place. Choose the disk size at instance creation time (for example, --create-disk=size=50 gives approximately 46 GB of container storage).

Enclave Vaults Integration

Enclave Vaults provides hardware-isolated key storage inside SGX enclaves. When used as the key source for Enclave OS Virtual:

1. The operator stores data encryption keys in the Enclave Vaults constellation using Shamir secret sharing. Each key is split across multiple vault nodes; no single node holds the complete key.
2. At container load time, the workload launcher connects to the vault constellation via mutual RA-TLS.
3. The vaults verify the VM's RA-TLS certificate (checking the TDX quote, RTMR measurements, and dm-verity root hash) before releasing key shares.
4. The launcher reconstructs the key from the shares and uses it to open or format the container's LUKS2 volume.

This creates a closed attestation loop: the VM must prove it is running trusted code before it can access keys, and the vault must prove it is running trusted code before the VM accepts the key.

Attestation of Encryption Status

The encryption key origin is embedded in RA-TLS certificates at two levels:

A client verifying the RA-TLS certificate can confirm:

• Whether data at rest is encrypted.
• How the key is held: on the Enclave Vaults constellation and gated on the machine's attested identity (vault: — the handle names the exact key), or operator-provided (legacy BYOK).
• The SHA-256 fingerprint of the key (for BYOK), allowing the client to confirm the expected key is in use without revealing the key itself.