Disk Encryption: AES-XTS, Master Keys & TPM Secrets

Full Disk Encryption (FDE) doesn’t just scramble your files; it makes the very concept of "unencrypted data" on a drive disappear until you authenticate.

Let’s watch FDE in action with a common scenario: a laptop that’s been powered off and then turned back on.

Imagine you boot up your laptop. Before the operating system even starts loading, the FDE software intercepts the boot process. It needs to unlock the drive so the OS can be read. This is where you see the prompt for your password or recovery key.

# Example: LUKS prompt during boot (often integrated into GRUB or systemd-boot)
# You'll see something like this on screen:
# Please unlock disk /dev/sda2_crypt:
# Enter passphrase:

Once you provide the correct passphrase, the FDE software uses it to derive a master encryption key. This master key is then used to decrypt a small portion of the disk that contains the actual volume key. The volume key is what’s used to decrypt the rest of your data. The master key is then discarded from memory, and only the volume key (which is itself encrypted) remains accessible to the OS. This whole process happens in the bootloader, before the OS kernel is even loaded, ensuring that no unencrypted data is ever exposed during the boot sequence.

The core problem FDE solves is data at rest security. If your laptop is lost or stolen, and it’s powered off, the data on the hard drive is completely inaccessible without the decryption key. It’s not just about locking files; it’s about making the entire storage medium appear as random noise to anyone without the key.

Internally, FDE systems like BitLocker (Windows), FileVault (macOS), and LUKS (Linux) all follow a similar pattern:

Pre-boot Authentication (PBA): This is the password or PIN prompt you see before the OS loads. It’s critical because it proves you have authorized access before any sensitive operating system files are read.
Key Derivation: Your passphrase/PIN is used to generate a strong encryption key. This is often done using a Key Derivation Function (KDF) like PBKDF2 or Argon2. The key derivation process is computationally intensive and helps protect against brute-force attacks on your passphrase.
Volume Key Encryption: The actual key used to encrypt/decrypt your data (the "volume key") is itself encrypted using the derived master key. This encrypted volume key is stored in a small, unencrypted (or lightly protected) area on the disk, often in the Master Boot Record (MBR) or a dedicated partition header.
Data Encryption: The rest of your drive’s data is encrypted using a strong symmetric cipher like AES (Advanced Encryption Standard) in a specific mode, typically XTS (XEX-based Tweaked Codebook mode), which is designed for block devices.
Runtime Decryption: When the OS needs to access data, the FDE driver (part of the OS or a pre-boot module) intercepts the request. It uses the volume key (which is now decrypted in memory) to decrypt the requested data on the fly. When the data is written, it’s encrypted on the fly before being written back to disk.

Let’s look at some configuration specifics.

LUKS (Linux Unified Key Setup)

LUKS is the standard for Linux. It’s a specification for disk encryption that is implemented by various tools.

Setup Command:
```
sudo cryptsetup luksFormat /dev/sdXn
```
This initializes a partition (/dev/sdXn) with LUKS headers. You’ll be prompted to enter a passphrase twice.
Opening a LUKS volume:
```
sudo cryptsetup open /dev/sdXn crypted_volume_name
```
This will prompt for your passphrase. If successful, a new device mapper device (/dev/mapper/crypted_volume_name) will be created, which you can then format with a filesystem (e.g., mkfs.ext4 /dev/mapper/crypted_volume_name).
Closing a LUKS volume:
```
sudo cryptsetup close crypted_volume_name
```
This unmounts the filesystem and securely erases the volume key from memory.

BitLocker (Windows)

BitLocker integrates tightly with Windows. It can use a Trusted Platform Module (TPM) for automatic unlocking on boot or require a PIN/USB key.

Enabling BitLocker (GUI): Navigate to "Control Panel" -> "BitLocker Drive Encryption". Select the drive, choose "Turn on BitLocker," and follow the prompts to set a password, save recovery keys, or configure TPM.
Enabling BitLocker (PowerShell):
```
Enable-BitLocker -MountPoint "C:" -TpmProtector
```
This command enables BitLocker on the C: drive using the TPM. You can use -PasswordProtector for a password or -StartupKeyProtector for a USB key.
Key Management: BitLocker stores recovery keys in Active Directory, your Microsoft account, or a file.

FileVault (macOS)

FileVault uses XTS-AES 128-bit encryption and integrates with the macOS login process.

Enabling FileVault (GUI): Go to "System Preferences" -> "Security & Privacy" -> "FileVault." Click "Turn On FileVault" and enter your user password. macOS will generate a recovery key that you must store securely.
Underlying Mechanism: FileVault uses CoreStorage or APFS logical volumes to manage the encrypted data. When you log in with your user account, your login password is used to unlock the encrypted volume.

A subtle but important point is how FDE handles "deleted" files. When you delete a file on an FDE-encrypted drive, the blocks it occupied are marked as free by the filesystem. However, the encrypted data for that file still resides on the disk until those blocks are overwritten by new data. This means that traditional file recovery tools will only be able to recover encrypted gibberish unless they can somehow obtain the decryption key and the FDE system’s metadata. The actual data isn’t "erased" in the secure sense until it’s overwritten, but its recovery is rendered moot by the encryption.

The next hurdle you’ll encounter is understanding how to securely wipe encrypted drives or manage multiple encryption keys for a single volume.