The Secure Enclave: SEPOS, mailbox protocol, what the SEP actually does

The Secure Enclave glossary entry introduced what the SEP is. This article goes one level deeper: what the SEP's OS looks like, the mailbox protocol that bridges it to the main CPU, the specific operations that cross the boundary, and what attack patterns the SEP is designed to defeat.

A separate computer on the same die

The SEP — Secure Enclave Processor — is, physically, a separate ARM core on every Apple Silicon SoC (and on T1/T2 chips in older Intel Macs). It has:

• Its own ARM CPU (a single core, much smaller than the main P/E cores).
• Its own dedicated RAM, isolated from main DRAM.
• Its own ROM that bootstraps its OS.
• Direct hardware access to the storage controller's AES engine.
• A dedicated I/O channel — the mailbox — to the main CPU.
• No access to main DRAM. No access to the main CPU's caches.

The isolation is physical. The main CPU cannot read SEP memory, period. It can only send mailbox messages to the SEP and wait for replies.

SEPOS — the SEP's operating system

The SEP runs its own OS called SEPOS, derived from L4 — a stripped-down microkernel architecture chosen specifically for its small trusted code base. Not Mach (despite XNU's lineage); a different kernel family for the different design requirements.

What SEPOS does:

• Provides the SEP's own scheduling, memory management, IPC.
• Hosts a small set of services — sks (Secure Key Service), sse (Secure Element), sep_filesystem for storage-backed secrets.
• Communicates with the main CPU only through the mailbox.

SEPOS is closed-source. Some details are documented in Apple's Platform Security Guide; some come from third-party reverse engineering.

The mailbox protocol

The main CPU and SEP communicate through a mailbox — a small set of hardware registers serving as a bidirectional ring buffer. Either side can write a message into its outbox; the other side gets an interrupt and reads from its inbox.

Messages have:

• An endpoint — which SEPOS service the request is for (key derivation, signing, attestation, etc.).
• A tag — request ID for matching replies to requests.
• A payload — the request data.

The XNU side of the mailbox is in the AppleSEP driver. It's a normal IOKit driver that:

• Owns the hardware mailbox registers.
• Receives interrupts from the SEP on incoming messages.
• Exposes high-level operations to other kernel subsystems via a private KPI.

Userspace can't talk to the SEP directly. Every request goes through the kernel (via SecKeyRef APIs, LocalAuthentication framework, the Keychain), which validates the request and forwards it via the mailbox.

What the SEP actually does

A non-exhaustive list of operations that happen inside the SEP:

• Password / passcode verification — user-typed password is routed (via SecureKeyboardEntry) to the SEP; the SEP derives a key, compares against the stored verifier.
• Touch ID / Face ID matching — biometric features are extracted in the biometric hardware (a separate subsystem with its own secure boot chain), passed to the SEP, matched against enrolled templates.
• Keychain access — sensitive Keychain items (anything marked kSecAccessControlBiometryAny) live wrapped under SEP-held keys. Access requires the SEP to decide.
• FileVault unlock — the SEP unwraps the VEK (volume encryption key) after the user authenticates.
• Apple Pay tokenization — DAN (device account numbers) and PAN-to-DAN mappings live in the SEP.
• App Attest and DeviceCheck — the device's attestation key, used to prove "this is a genuine Apple device, in genuine state X."

A real example: unlocking a Keychain item

User wants Safari to autofill a saved password (a Keychain item marked biometry-protected):

1. Safari requests the item via SecItemCopyMatching.
2. macOS notices the item is biometry-gated; prompts Touch ID.
3. User touches the sensor.
4. Biometric subsystem sends features to SEP via SEP's dedicated bus (not via main CPU memory).
5. SEP matches against enrolled template. On match: SEP unwraps the Keychain item's wrapping key.
6. SEP encrypts the wrapping key with a per-session ephemeral key shared with the kernel (set up via Diffie-Hellman over the mailbox at boot).
7. SEP returns the ephemerally-encrypted wrapping key via mailbox.
8. Kernel decrypts using the session key; uses the wrapping key to unwrap the Keychain item's data.
9. Returns the data to Safari.

Note: the SEP itself never returns the unwrapped key in cleartext over the mailbox. It returns ephemerally-encrypted material. This protects against an attacker who can passively observe mailbox traffic — they can't extract the wrapping key.

Threat model: what the SEP defends against

The SEP is designed to remain secure against:

• A complete kernel exploit on the main CPU. Even if the kernel is compromised, the SEP refuses to perform authenticated operations without satisfying its own preconditions (e.g., re-verifying the user password before releasing the FileVault key on each cold boot).
• Physical memory probing of main DRAM. The SEP's memory is not main DRAM.
• Side-channel attacks on the mailbox. The wire protocol uses session keys; replay attacks fail because tags are tied to nonces.
• Boot-time tampering. SEPOS is verified by its own ROM at SEP boot; the main system can't influence SEP boot.

What the SEP cannot defend against:

• Physical destruction of the SEP itself. Anyone with the chip in a lab can attempt invasive attacks — Apple's defenses here are physical (mesh, voltage detectors) but not perfect.
• Compromised user input. If the user types their password into a phishing dialog under malware control, the password is exposed in the malware — SecureKeyboardEntry only protects against this for system-trusted prompts.
• Logic flaws in SEPOS. Bugs in the SEP's own code can be exploited; Apple has shipped SEPOS updates to patch such bugs in past releases.

The DH session at boot

When the system boots, the kernel and SEP perform a Diffie-Hellman key exchange over the mailbox, establishing a session key. From then on, sensitive data crossing the mailbox is encrypted with the session key.

This is why even a passive mailbox observer can't extract Keychain wrapping keys: the keys are encrypted with a session key only the kernel and SEP know.

Boot of the SEP itself

The SEP boots independently of the main system:

1. SEP's own Boot ROM runs first.
2. Boot ROM loads sepfw from the SoC's flash and verifies its Apple signature.
3. sepfw (the SEPOS image) starts and brings up its services.
4. Once SEPOS is up, it signals readiness on the mailbox.
5. The main CPU's iBoot waits for this signal before continuing kernel boot.

The SEP boot completes before the main system is alive enough to do anything meaningful. By the time XNU's kernel_init runs, the SEP is already serving requests.

What surprises newcomers

• The SEP is its own complete computer. Own CPU, own RAM, own OS, own boot chain. It just happens to share a die with the main system.
• Kernel exploits don't equal SEP exploits. The SEP refuses to honor any request that doesn't meet its own internal preconditions, even from the kernel.
• The SEP can be updated. SEPOS has shipped patches in OS updates — see Apple's security bulletins for past SEP CVEs.
• The biometric hardware isn't the SEP. Touch ID/Face ID have their own secure subsystem; features are passed to the SEP via a dedicated bus, not via main memory.

What to read next

For the public-facing API the kernel exposes the SEP through:

And Apple's Platform Security Guide for the definitive (closed-source-friendly) documentation of every operation that involves the SEP.

For the chain of trust the SEP roots, see the code signing chain article.