IPLS: Privacy-Preserving Storage for Your WhatsApp Contacts
Meta built Identity Proof Linked Storage (IPLS) to let WhatsApp users back up and restore their contacts without ever exposing them to the server.
Encrypting messages in transit is the easy story — what happens when the thing you need to protect is the address book that makes those messages possible? WhatsApp had default end-to-end encryption for years before it had a principled answer to that question.
Source
IPLS: Privacy-preserving storage for your WhatsApp contacts
By: Meta
Published: Oct 22 2024
Type: Engineering article
Saved because IPLS is a concrete system design — not a threat model or a whitepaper — that shows how key transparency and hardware security modules can be composed to protect data at rest without trusting the server.
How IPLS works
Before IPLS, WhatsApp contacts lived on the device. Lose the phone, lose the list. There was no server-side backup because backing up contact names server-side would mean Meta could read them. IPLS resolves this by keeping the contact encryption key on the client and only storing a protected copy of that key in a hardware security module (HSM), never in plain software storage.
The system is built on two existing WhatsApp primitives. The first is the Auditable Key Directory (AKD), already used by WhatsApp’s key transparency system. The AKD maps phone numbers to the cryptographic identity keys of primary devices and is append-only — entries can be added but never silently modified. When you install or reinstall WhatsApp, a new keypair is created and a record of the identity key is published to the AKD. This makes your device’s identity publicly auditable: anyone, including the WhatsApp client itself, can verify that a given phone number is tied to a given key at a given time.
The second building block is the HSM-based Key Vault, which already underpins WhatsApp’s end-to-end encrypted backups. HSMs are tamper-resistant hardware that execute code in a security boundary opaque even to Meta’s own privileged engineers. Data going in and out of the vault travels over an end-to-end encrypted channel established between the client and the HSM, not Meta’s servers.
IPLS threads these two systems together. When you save a contact, your device generates a symmetric encryption key, encrypts the contact name locally, and sends the contact key to the Key Vault over the encrypted channel. The vault accepts the key only after the HSM verifies your device’s identity against the AKD — a cryptographic handshake that proves you hold the private key corresponding to the phone number registered in the directory. The encrypted contact data itself is stored server-side, but neither Meta nor anyone else can decrypt it without the contact key, which sits only in the vault and on your device.
Restoring after a phone loss follows the same path in reverse. The new device registers, creates a new identity keypair, and the AKD is updated. The Key Vault then allows the new device to retrieve the contact encryption key by verifying the new device’s identity against the AKD and confirming possession of the corresponding private key. The contacts come back without any human intervention from Meta’s side.
To prevent a scenario where a compromised or rogue version of the AKD silently maps your number to an attacker’s key, Meta brought in Cloudflare as an independent witness. Cloudflare signs each AKD epoch — a snapshot of the directory at a point in time — and returns a digital signature that the Key Vault validates before trusting any identity claim. The Key Vault will refuse to update the AKD if Cloudflare’s signature is absent, making it structurally impossible to modify the directory unilaterally. Consistency proofs across epoch transitions are published to a public, write-once Amazon S3 bucket so any external auditor can verify the chain.
The external review component is worth noting separately. The full system was reviewed by NCC Group Cryptography Services, and the cryptographic properties were audited with Cloudflare’s involvement. Shipping a novel encrypted storage scheme at this scale without external review would be a notable gap — the fact that Meta didn’t skip it matters.
For users, the visible result is that contacts sync across linked devices and can be restored on a new phone. For engineers, what’s interesting is that none of this required Meta to see the contact names. The server stores encrypted blobs. The HSM enforces who can retrieve the key. The AKD and Cloudflare attestation ensure the identity check cannot be forged without public evidence of tampering.
My take
What this reveals is that “end-to-end encrypted” is not a single property — it’s a family of claims that have to be made about different parts of a system independently. WhatsApp had E2E messaging for years but the contact list, which is the prerequisite for using those messages usefully, sat outside that protection. IPLS closes a real gap rather than paper over it.
The Cloudflare witness pattern is the most transferable idea here. It converts what would otherwise be a unilateral trust claim — “trust our append-only log” — into a two-party check with a public paper trail. Any system that relies on an append-only directory for security guarantees should ask whether a third-party witness and public consistency proofs would meaningfully raise the cost of attack.
Where this is useful
- Designing server-side storage for client-generated secrets when zero-knowledge from the server is required
- Systems that need backup and recovery without a “forgot password” flow that implies server-side key knowledge
- Anywhere you want a third-party attestation on a shared log without giving that third party read access to the data
- Not useful when the threat model includes the user’s own device — IPLS assumes device integrity as a starting point
Apply this: Before storing any user secret server-side, identify whether an HSM with an independently audited access policy eliminates the need to trust the server operator.
What I want to remember
Remember: An append-only log is only trustworthy if someone independent can verify it hasn’t been forked — a third-party witness with public consistency proofs is the structural solution, not an audit report.