Skip to content

Security architecture

Privy's security architecture combines distributed key sharding with secure execution environments to protect your users' assets. Simply put:

  • Keys are only stored as encrypted shares distributed across separate security boundaries.
  • Keys are only temporarily reconstructed within secure execution environments when needed for specific operations, under the wallet owner's control.

Core security model

Every sensitive cryptographic operation in Privy occurs within a secure execution environment—an isolated context with strict security guarantees. Whether running in a browser-enforced iframe or hardware-secured enclave, these environments ensure private keys are protected throughout their lifecycle.

When a user creates a wallet, the secure execution environment generates strong entropy (128 bits) from a cryptographically secure random number generator (CSPRNG). This is converted to a mnemonic using BIP-39, from which Privy derives the wallet's public key and private key. All Privy wallets are hierarchical deterministic (HD) wallets.

Immediately after creation, the wallet entropy is sharded into key shares, and the key shares are encrypted and distributed across separate security boundaries. This ensures that wallets can never be accessed outside of the secure execution environment.

Secure Key Management

INFO

Private keys only exist in complete form temporarily within secure execution environments during signing operations. At all other times, they remain split into encrypted shares stored across separate security boundaries.

Concepts

Secure execution environments

Secure execution environments are processing containers with strong isolation properties. These environments protect sensitive operations even if the host system is compromised.

Privy provides two types of secure execution environments that protect sensitive operations through multiple independent security boundaries. Each environment ensures that private keys are never stored in complete form and are only temporarily reconstructed when needed.

Secure environments on user devices

To secure wallets directly on user devices, Privy uses browser-enforced isolation via iframes. This leverages the browser security boundaries that have been battle-tested for decades, securing billions of dollars in daily financial transactions across the modern internet.

When wallets are secured on-device, all key operations happen directly on the user's device, and signature generation is extremely fast (20 ms). Learn more.

Trusted execution environments

Privy offers full wallet functionality via a REST API, secured using trusted execution environments (TEEs).

TEEs are highly restricted, isolated compute environments that allow for secure code execution in a server environment. This enables API-level flexibility and programmable server-side controls. Learn more.

INFO

You can choose which secure execution environment to use to provision wallets. By default, Privy provisions self-custodial user wallets directly on user devices, secured by browser-enforced isolation.

Alternatively, you can integrate Privy's powerful APIs directly to configure TEE-secured wallets with fully flexible controls.

Key share management

Privy's security model is based on distributed key sharding. This means critical key entropy is split into encrypted shares stored across separate security boundaries.

Key sharding enables future-proof flexibility, strict security isolation, and built-in recovery.

  • In particular, key sharding enables separate authentication and encryption of each distributed share, enforcing control by wallet owners.
  • Beyond this, key sharding makes it possible to configure backups and redundancy so you and your users always have access to their keys, even if Privy is not available.

Key sharding and assembly only ever occur within the secure execution environment. Private keys are split into encrypted shares using a reliable, battle-tested, and fast cryptographic algorithm called Shamir's secret sharing (SSS). No share in isolation provides any information or access to the wallet.

INFO

Privy's shamir-secret-sharing cryptography library is open-source, heavily audited, and used to secure millions of user accounts. It is the most widely used open-source Typescript library for Shamir's secret sharing.

There are three share types, protected by different security boundaries:

  • Device/enclave share: Encrypted and secured directly by the secure execution environment, on user's device or by the secure enclave (TEE). In client web integrations, this device share is stored in the browser's domain-partitioned local storage, on the user's device. In direct API integrations, the TEE serves as the user's remote device.

  • Auth share: Encrypted and stored by Privy, accessible only with valid authentication through a secure execution environment.

In the case of on-device secure execution environments, the recovery share is used to provision the wallet on new user devices. This share is encrypted and secured either through user-managed methods (password or cloud backup) or Privy's recovery key management system.

Two shares must be present to reconstruct the private key, which only happens temporarily within secure execution environments. By default, a device-specific share and an auth share are provisioned for each device on which a wallet is used.

Secure operations

Wallet private keys only exist in-memory within the secure execution environment, e.g. the isolated iframe or TEE. The private key does not persist past the secure execution environment's lifetime.

This process ensures:

  • Keys exist only as encrypted shares stored across separate security boundaries
  • Shares are only combined temporarily within the secure environment for specific operations
  • Network access is strictly controlled
  • Every operation requires proper authentication

Read more about key reconstitution on user devices and in trusted execution environments.

Signing using key shares

Protecting code deployments to secure execution environments

Privy enforces strict controls of the code deployments within these environments. Code deployed to secure execution environments undergo extensive review and security controls, including strict multi-party approvals.

All code changes require review from multiple designated owners, must pass automated security testing, and go through staged deployments with additional approvals. The Privy CI/CD pipeline ensures build artifacts are deployed directly from protected source code, with branch protection rules and signing requirements. This process is regularly audited and monitored to prevent unauthorized modifications.