Encryption at Rest

What at-rest encryption actually protects

Encryption at rest protects against attackers who have the storage media but not access to a running system that knows the key. Concrete threats it handles:

• Stolen laptop or phone.
• Drives removed from a decommissioned server.
• Hardware retrieved from electronic-waste recycling.
• Storage seized by authorities (depending on jurisdiction and what they can compel).
• Drives shipped between locations.

What it doesn't protect:

• Attacker with running access to the system. The system has the key, so the attacker reads decrypted data.
• Ransomware running on the live system. Same reason.
• Malicious or compromised users with legitimate credentials.
• Network attacks. That's encryption in transit.

The encryption layers

Self-Encrypting Drives (SED)

The drive controller does AES encryption internally with a key stored on the drive itself. The OS sees a normal disk. Performance is essentially identical to unencrypted because the cipher runs in dedicated hardware.

Pros:

• Zero CPU overhead.
• Transparent to applications and OS.
• Crypto-erase: instantly "wipe" the drive by destroying the key, no need to overwrite every block.

Cons:

• Trust in the drive vendor's implementation. Past audits have found vulnerabilities in specific drives.
• Key management depends on the host (TPM, ATA password, or TCG Opal authentication).
• Hard to verify the encryption is correct without disassembly.

Block-device encryption

The OS encrypts every block written to a volume. The encrypted volume looks like random data; mounting requires the key.

• LUKS / dm-crypt — the Linux standard. Uses LUKS as the metadata format on top of dm-crypt block-level encryption.
• BitLocker — Windows. Integrates with TPM for key unsealing.
• FileVault 2 — macOS. Hardware-accelerated on Apple Silicon.

Block-device encryption is the most-recommended pattern for laptops and any storage whose drives might leave the building. Performance impact on modern CPUs with AES-NI is small (single-digit percent or less).

Filesystem-level encryption

Encryption applied per-file or per-dataset rather than per-volume. Benefits:

• Different keys for different datasets — useful for multi-tenant systems.
• Some files encrypted, others not — fast access for non-sensitive data.
• Per-user keys — each user's files encrypted with their key.
• For ZFS specifically: encryption integrates with snapshots, send/receive, and the integrity-verification stack.

Drawbacks:

• Metadata may leak — file sizes, timestamps, names depending on implementation.
• More complex than full-volume encryption.

Application-level encryption

The application encrypts data before storing it. The storage layer sees only ciphertext. Used for highly-sensitive data where no infrastructure component should see plaintext: medical records, financial data, regulatory compliance.

• Most control over key management.
• Storage layer can be untrusted.
• Most complexity — every query, search, and update has to handle encrypted data.

Database-level encryption (TDE — Transparent Data Encryption in MySQL/PostgreSQL/SQL Server) is the middle ground: the database engine encrypts at the file level, transparently to applications.

Key management: the hard part

The encryption algorithm isn't the hard part — AES-256 with proper modes is essentially unbreakable in any practical sense. The hard part is what holds the key and how it gets to the system that needs it.

Key rotation

Most encryption schemes separate the master key from the data-encryption key. Rotating the master key (KEK) periodically is good practice; the data isn't re-encrypted because the data key (DEK) stays the same, but the KEK protecting the DEK changes. This limits damage if the KEK is compromised.

Re-encrypting actual data is much more expensive — every block must be decrypted and re-encrypted with the new key. Typically done only when there's a specific compromise or major policy change.

Backups and encryption

Encrypted source data going to a backup target has options:

• Decrypt at source, re-encrypt at backup target. Backup sees plaintext briefly; backup encryption is independent.
• Stream encrypted blocks directly. Backup target stores ciphertext; can't be read without the source key. Restore requires the source key.
• Both endpoints have the key. Most common pattern.

For off-site / cloud backups, encrypting before upload (client-side encryption) is recommended. The cloud sees only ciphertext; cloud-provider compromise doesn't expose backup contents.

The decommissioning angle

Encryption at rest dramatically simplifies disk decommissioning. Instead of overwriting every block (slow) or physically destroying the drive (wasteful), crypto-erase destroys the key. The disk's data becomes unrecoverable instantly, even though the bits remain on the disk.

This is one of the largest operational wins of at-rest encryption: returning equipment to lease, selling old hardware, or recycling drives becomes safe without slow wipe procedures.

Common mistakes

• Key stored next to data. Defeats the entire purpose.
• Reusable passphrase across all systems. One leak compromises everything.
• No key backup. Lose the key, lose all the data. (Have escrow / recovery process.)
• Trusting unverified hardware encryption. Some SEDs have had implementation flaws.
• Encrypting but not encrypting backups. Backups carry the same data; they need the same protection.
• Thinking encryption-at-rest stops ransomware. It doesn't.

Frequently Asked Questions

What is encryption at rest?

Encryption of data while it is stored on disk, as opposed to encryption in transit (TLS, SMB encryption) which protects data while it moves over networks. At-rest encryption protects data when the storage media is physically separated from the running system — stolen disk, decommissioned drive, retrieved-from-trash hardware. It does not protect against attacks on the running system itself.

What is the difference between full-disk and filesystem encryption?

Full-disk encryption (LUKS, BitLocker, FileVault, dm-crypt) encrypts the entire block device; everything written to the disk is encrypted, including the filesystem metadata. Filesystem-level encryption (eCryptfs, EncFS, native ZFS encryption) encrypts files or datasets individually; some data can be encrypted and other data not. Full-disk is simpler and protects more; filesystem-level allows per-dataset key separation.

What is SED (Self-Encrypting Drive)?

A drive that does encryption in its own hardware controller using a key stored in the drive itself. The OS sees a normal disk; encryption is transparent and adds essentially zero CPU overhead. The key is unlocked at boot via an authentication mechanism (TCG Opal, ATA security). SEDs make encryption free in performance terms but require trust in the drive vendor's implementation.

Does encryption at rest protect against ransomware?

No. Encryption at rest decrypts data on read for any process running on the system. Ransomware running as a user with access to the data reads and re-encrypts it just like any other process. The encryption layer is invisible to applications. Backups, immutable storage, and access controls protect against ransomware; encryption-at-rest does not.

Where should the key be stored?

The single hardest question. Options: TPM (key sealed to the boot state of this specific machine), KMS (key stored in a separate management service), passphrase (key derived from human input each boot), USB token (key on a removable device), HSM (hardware security module). Each has different trust and operational implications. The right answer depends on threat model and tolerance for downtime if the key is lost.