APFS encryption: FileVault, per-file keys, and the SEP's role

On macOS 10.13+, every byte you write to disk is encrypted. Not by user choice — by default, by the hardware. FileVault is no longer a feature you turn on to encrypt your disk; it's a feature you turn on to gate decryption behind your password. The underlying encryption is always there.

This article walks how that encryption actually works — the keys, the SEP's role, where the AES happens, and what FileVault changes.

The key hierarchy

Encryption on modern Macs is layered:

• Per-file key (FK) — a unique AES-XTS key for each file. Generated by the SEP at file creation.
• Per-class key (PK) — wraps the per-file key. Multiple classes exist with different protections (e.g., "available always" vs "available only after user unlock").
• Volume encryption key (VEK) — wraps the per-class keys.
• Key encryption key (KEK) — wraps the VEK. The KEK is what user password / biometric unwrap.

When you read a file:

1. The kernel reads the per-class key (already in memory if the device is unlocked).
2. Uses it to unwrap the per-file key from the file's metadata.
3. Uses the per-file key to decrypt the file's contents.

When you write, the chain runs in reverse — encrypt with per-file key, store metadata wrapped with per-class key.

Where the AES actually happens

On Apple Silicon, AES is not done by the CPU. It's done by a hardware engine in the SSD controller itself — the storage controller has dedicated AES blocks that encrypt/decrypt at line rate.

The CPU's role:

1. Compute the right per-file key (using the per-class key it has in memory).
2. Hand the key to the SSD controller along with the I/O request.
3. The SSD controller does the actual encrypt or decrypt as the data flows through.

The result: block-level FileVault performance is identical to unencrypted on Apple Silicon. AES happens in dedicated silicon at zero CPU cost. Older Intel Macs paid a measurable cost (a few percent of disk bandwidth); Apple Silicon doesn't.

The Secure Enclave's role

Several things in the key hierarchy never leave the Secure Enclave:

• The device UID — fused into the chip at manufacture, never readable.
• The KEK — derived in the SEP from the user's password + device UID + a hardware secret.
• The user authentication state — the SEP tracks whether the user has unlocked, for how long, with what method (password / Touch ID / Face ID).

When a user authenticates, the SEP unwraps the VEK and hands it to the kernel's memory. The kernel uses the VEK to unwrap per-class keys; per-class keys live in kernel memory for the duration of the unlock window.

Critically: the password itself never enters the main CPU's normal memory. It's typed into a SecureKeyboardEntry control that ships the keystrokes directly to the SEP via a side channel. The SEP processes the password, derives the KEK, unwraps the VEK, returns the VEK. The CPU sees the VEK; the password is never in main RAM.

This is why a kernel exploit on the main CPU doesn't immediately compromise FileVault: the password derivation happened in the SEP, the VEK is in kernel memory only if the device is unlocked, and locking the device causes the kernel to wipe the VEK from memory.

What FileVault changes

If encryption is always on, what does turning on FileVault do?

• Before FileVault: the VEK is wrapped by a key derived from the hardware alone (no user secret). The kernel can unwrap the VEK at boot without user input. Disk is encrypted, but unauthorized boot still works.
• After FileVault: the VEK is wrapped by a key derived from the user password + hardware. The kernel needs the user to type the password to unwrap the VEK. Without the password, disk contents are inaccessible.

In both cases, the AES on disk is identical. The difference is whether unwrapping requires a user secret.

This is why "turning on FileVault" is fast on modern Macs — it doesn't re-encrypt the disk (everything was already encrypted), it just changes how the VEK is wrapped. The actual disk content stays put.

Per-class keys and Data Protection

iOS pioneered the Data Protection classes; modern macOS uses them too:

• Class A — Complete Protection — keys wiped immediately on device lock. Files inaccessible until unlock.
• Class B — Protected Unless Open — files can be opened before lock; the open file stays accessible after lock until closed.
• Class C — Protected Until First User Authentication — accessible after the first unlock-after-boot, then accessible until reboot.
• Class D — No Protection — keys derived from hardware only; accessible at any time, including before user unlock.

On macOS, most user files are Class C — once you've logged in for the first time, the keys stay available. iOS uses Class A for sensitive files like the Mail app's database.

The class system is what lets your Mac wake from sleep and continue serving notifications, downloads, syncs without re-prompting for the password — Class C keys are still live in the kernel.

Per-file keys — uniqueness matters

Why a per-file key? Two reasons:

1. Forensic isolation. A leaked key (say, an attacker reads kernel memory and extracts one) compromises one file, not the whole disk.
2. Secure deletion. Deleting a file means destroying its per-file key. The encrypted blocks on disk become unreadable, even though the bits are still there. APFS marks per-file keys as deleted in metadata; the wear-leveling SSD eventually overwrites the blocks at its leisure.

The per-file key is generated by the SEP at file creation, wrapped with the per-class key, and stored in the file's metadata. There's one per file — millions of unique keys on a typical Mac.

What surprises newcomers

• Disk is encrypted whether or not FileVault is on. FileVault gates the key; the encryption is unconditional.
• Decryption happens in the SSD controller, not the CPU. AES is essentially free on Apple Silicon.
• The SEP is the only thing that ever sees your password. Even kernel memory never holds the cleartext.
• Per-file keys make secure delete trivial. Throwing away the metadata key makes the file blocks permanently unreadable.

What to read next

For the open-source bits Apple does publish:

apple-oss-distributions/SecurityOSX/libsecurity_keychain/lib/Keychain.cppKeychain — the high-level storage SEP-protected keys are exposed through.View on GitHub(line —) apple-oss-distributions/xnubsd/vfs/vfs_subr.cVFS plumbing — APFS's encryption is one layer below vfs from the kernel's view.View on GitHub(line —)

For the full architecture, Apple's Platform Security Guide is the definitive document.

And the APFS overview for the on-disk format encryption is layered onto.