system design · system-design · domain
Design iMessage, End-to-End Encryption + Delivery
Apple ICT3+ canonical system design. Tests asymmetric crypto, multi-device key fan-out, offline delivery, and the privacy-first architecture Apple grades senior candidates on.
Theory
Explanation
Intuition first, formal definition second. Skim the bullets if you already know this; read the prose if you don't.
The server delivers ciphertext it cannot read. The recipient device decrypts. This inverts the usual chat model, instead of one server-held conversation log, every message is N copies of ciphertext, one per recipient device, each encrypted under that device's public key. Apple never sees plaintext, never holds the private keys. Compromise of the server reveals only ciphertext metadata and timing.
Three subsystems: (1) Identity Directory (IDS), maps Apple ID → list of device public keys. Each device registers a long-term identity key + rotating ephemeral keys at provisioning. (2) Message Encryption, sender fetches recipient device keys from IDS, encrypts payload N times (once per device) with hybrid scheme: AES-CTR for body, RSA/ECIES for AES key wrap. (3) Delivery, APNs (Apple Push Notification service) routes encrypted blobs to devices. Devices acknowledge; server keeps ciphertext for offline delivery up to retention window, then drops.
When to use
Any messaging product where the server should not be able to read content: Signal, WhatsApp (Signal protocol), iMessage, end-to-end encrypted backups. The hybrid (symmetric body + asymmetric key wrap) keeps perf reasonable even on large messages.
When not to
When server-side features (search, ML moderation, anti-spam scanning of content) are required. E2EE blocks them by design. Workarounds (homomorphic encryption, on-device classifiers) exist but expensive.
sequenceDiagram autonumber participant S as Sender (iPhone) participant IDS as Identity Directory participant APNs as APNs Relay participant R1 as Recipient iPhone participant R2 as Recipient Mac S->>IDS: GET keys(recipient@icloud) IDS-->>S: [pubKey_iPhone, pubKey_Mac, ...] S->>S: encrypt body with AES-CTR · wrap AES key with each device pubKey S->>APNs: PUT ciphertext blobs (one per device) APNs-->>R1: push: ciphertext_iPhone APNs-->>R2: push: ciphertext_Mac R1->>R1: decrypt with privKey_iPhone R2->>R2: decrypt with privKey_Mac R1-->>APNs: ACK R2-->>APNs: ACK APNs->>S: delivery receipt
Key insights
- Multi-device is the hidden complexity. Each Apple ID maps to N devices; each message must be encrypted N times. Sender pays the fan-out cost.
- Hybrid encryption is mandatory. Pure RSA on a 100 KB image = ~100x slower than AES-CTR body + RSA-wrapped 256-bit key.
- IDS lookups are cached on-device with TTL. Fresh fetch only when contact unknown, TTL expired, or key fingerprint changed. Apple shows key-change warnings in newer iOS.
- Forward secrecy in classic iMessage was weak (long-term RSA). Modern iMessage Contact Key Verification + iMessage PQ3 (2024) add Diffie-Hellman ratchets and post-quantum KEMs.
- APNs decouples reachability. Sender never knows recipient is offline, it ships ciphertext to APNs, APNs queues, retries up to 30 days, delivers when device next checks in.
- Ordering is per-device, not global. Each (sender_device → recipient_device) channel maintains its own sequence number. UI merges by timestamp; no single server-side ordering exists.
- Plaintext never lands on Apple servers. Even crash logs, ML telemetry, and search indexing happen entirely on-device. This is the architectural bet Apple grades you on.