Introduction
World App is self-custodial: the user’s Root Key, wallet, World ID, etc. all live on their device. Backup & Recovery is what lets the user re-derive that state on a new device when the old one is lost/replaced without trusting any single party with the plaintext data. This system is particularly designed with distributed trust where no single party can compromise a user’s backup, in essence the lock and key are handled by independent parties and hardened independently. The backup is end-to-end encrypted on the client, stored as ciphertext by the Backup Service, and decryptable only with one of the user’s enrolled s (Passkey, OIDC account, iCloud Keychain keypair).System Overview
There are four main components involved in the system.- Client (iOS, Android): User-facing flows. Implements platform-specific factor logic and calls into Bedrock for shared crypto and manifest logic.
- Bedrock: Cross-platform library shared by both clients. Owns the backup file format, manifest computation, sealing/unsealing, and the Turnkey stamping primitives. See
bedrock. - Backup Service: A secure backend storage layer which holds the and , validates state transitions on sync, and exposes endpoints for factor management. It never sees the decrypted plain text, nor has it any way of accessing the ciphertext. The keys with which the ciphertext is encrypted are never seen by this service. See
backup-service. Currently this service is operated independently by Nethermind. - Turnkey — Holds s for OIDC factors inside its Trusted Execution Environment (TEE on AWS Nitro) and provably authenticates the user (via OIDC). Internally, TFH is the parent organization; each user is a sub-organization. Neither TFH or Turnkey can access the user’s secrets, this is enforced by the TEE.
Layered Encryption Model
The backup uses two layers of asymmetric encryption rather than a single password-derived key. This decouples factor lifecycle from backup content.
- The is the plaintext: a collection of files (the , PCPs, the credential vault) plus a manifest. Its structure is owned by Bedrock’s
BackupFormat. See Backup Structure & Sync. - The client encrypts the with a randomly generated at backup creation. The result is the .
- The client then encrypts the once per with that factor’s , producing s. The keypair’s secret key is then discarded — only the public key is kept locally so the client can re-encrypt new versions of the backup without authenticating a Main Factor.
- The s live in the alongside the list of factors.
The reason for the keypair indirection is that adding a new only requires re-encrypting the keypair (small) under the new , not the entire backup. Without it, copies of the would have to be maintained.
Threat Model
The system is designed to defend against:- Backup Service compromise. A breach of the Backup Service exposes ciphertext and metadata only. s never reach the service; the private key is destroyed after sealing.
- TFH backend compromise. TFH’s app-backend stamps Turnkey sub-organization creation but does not custody factor secrets or backup contents. An attacker with TFH backend access cannot decrypt a backup or even retrieve the ciphertext.
- Loss of a single device. Recovery only requires one enrolled .
- Loss of a single factor. Multiple Main Factors can be enrolled. Sync Factors are scoped narrowly (see Authentication Factors).
- Single party coercion. If a single party is coerced or malicious, they cannot compromise a user’s backup.
- Compromise of the user’s passkey provider or OIDC identity provider.
- Malware on the user’s device with access to plaintext after recovery.
- Coercion-resistant recovery (no duress codes).
- Rotation of long-lived keys (factor secrets, the backup keypair) is not currently supported.