Security architecture
Privy’s security architecture combines trusted execution environments (TEEs) with distributed key sharding 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 trusted execution environments when needed for specific operations, under the wallet owner’s control.
Concepts
Trusted execution environments
Trusted execution environments (TEEs), also known as secure enclaves, are highly restricted, isolated compute environments that allow for secure code execution and cryptographic verification (attestation) of the code being executed. In particular, Privy uses AWS Nitro Enclaves.
Privy uses TEEs to support private key reconstruction for the following processor-level guarantees:
- Enclaves have no persistent storage, no interactive access, and no network connectivity, and so provide a secure, isolated compute environment for sensitive data. Private keys for wallets are only accessible within the enclave, and can only be used to produce signatures compliant with the policies attached to the wallet.
- Attestations are cryptographic verifications of the computation run on a TEE. They are signed hashes of code on a enclave that can be verified with the corresponding public key, and can be used to verify actions run within the TEE.
Key shares
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 redundancy. In particular, key sharding enables separate authentication and encryption of each distributed share, enforcing control by wallet owners.
Key sharding and assembly only ever occur within the trusted 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.
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.
When a wallet is created, it is split into two shares, protected by different security boundaries:
- Enclave share, also referred to as the TEE share, which is secured directly by the trusted execution environment and encrypted with the TEE’s cryptographic key. The enclave share can only be decrypted within the TEE.
- Auth share, which is encrypted and stored by Privy. This share is accessible only with valid authentication credentials, e.g. a bearer token or secret, and is sent to the enclave whenever an action is requested from the wallet.
This is a 2-of-2 share set, which means that both shares are required in order to generate signatures. Neither the auth share nor the enclave share in isolation provide any information or access to the wallet.
Only the TEE can decrypt the enclave share and combine it with the auth share to temporarily reconstitute the wallet and execute actions.
Key management operations
Wallet creation
When a user creates a wallet, the trusted 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 TEE.
Private keys only exist in complete form temporarily within the trusted execution environment during signing operations. At all other times, they remain split into encrypted shares stored across separate security boundaries.
Wallet transaction
When a wallet transaction is requested, the wallet private key is reconstituted temporarily in-memory within the trusted execution environment. Two shares must be present to reconstruct the private key, the enclave share and auth share. The private key does not persist beyond usage for the wallet operation.
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
In more detail, when signing a transaction:
- Your app makes a
POSTrequest to the Privy API with the appropriate bearer token (typically the Privy app secret) and an authorization key signature. - Privy’s backend authenticates the bearer token. If the request is valid, the request is forwarded to the TEE, along with the auth share.
- The TEE verifies the authorization signature from your request against the authorization public key.
- The TEE decrypts its encrypted device share and combines it with the auth share to reconstruct the wallet’s private key.
- The key is used temporarily in-memory for cryptographic signing.
- The transaction signature is returned to your application.
Privy also supports broadcasting the signed transaction to the blockchain, directly from the API.
Protecting code deployments to the trusted execution environment
Privy enforces strict controls of the code deployments within the trusted execution environment. Code deployed to the TEE undergoes extensive review and security controls, including strict multi-party approvals and hardware security key requirements.
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, security scanning, and signing requirements. This process is regularly audited and monitored to prevent unauthorized modifications.
Security architecture
Privy’s security architecture combines trusted execution environments (TEEs) with distributed key sharding 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 trusted execution environments when needed for specific operations, under the wallet owner’s control.
Concepts
Trusted execution environments
Trusted execution environments (TEEs), also known as secure enclaves, are highly restricted, isolated compute environments that allow for secure code execution and cryptographic verification (attestation) of the code being executed. In particular, Privy uses AWS Nitro Enclaves.
Privy uses TEEs to support private key reconstruction for the following processor-level guarantees:
- Enclaves have no persistent storage, no interactive access, and no network connectivity, and so provide a secure, isolated compute environment for sensitive data. Private keys for wallets are only accessible within the enclave, and can only be used to produce signatures compliant with the policies attached to the wallet.
- Attestations are cryptographic verifications of the computation run on a TEE. They are signed hashes of code on a enclave that can be verified with the corresponding public key, and can be used to verify actions run within the TEE.
Key shares
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 redundancy. In particular, key sharding enables separate authentication and encryption of each distributed share, enforcing control by wallet owners.
Key sharding and assembly only ever occur within the trusted 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.
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.
When a wallet is created, it is split into two shares, protected by different security boundaries:
- Enclave share, also referred to as the TEE share, which is secured directly by the trusted execution environment and encrypted with the TEE’s cryptographic key. The enclave share can only be decrypted within the TEE.
- Auth share, which is encrypted and stored by Privy. This share is accessible only with valid authentication credentials, e.g. a bearer token or secret, and is sent to the enclave whenever an action is requested from the wallet.
This is a 2-of-2 share set, which means that both shares are required in order to generate signatures. Neither the auth share nor the enclave share in isolation provide any information or access to the wallet.
Only the TEE can decrypt the enclave share and combine it with the auth share to temporarily reconstitute the wallet and execute actions.
Key management operations
Wallet creation
When a user creates a wallet, the trusted 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 TEE.
Private keys only exist in complete form temporarily within the trusted execution environment during signing operations. At all other times, they remain split into encrypted shares stored across separate security boundaries.
Wallet transaction
When a wallet transaction is requested, the wallet private key is reconstituted temporarily in-memory within the trusted execution environment. Two shares must be present to reconstruct the private key, the enclave share and auth share. The private key does not persist beyond usage for the wallet operation.
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
In more detail, when signing a transaction:
- Your app makes a
POSTrequest to the Privy API with the appropriate bearer token (typically the Privy app secret) and an authorization key signature. - Privy’s backend authenticates the bearer token. If the request is valid, the request is forwarded to the TEE, along with the auth share.
- The TEE verifies the authorization signature from your request against the authorization public key.
- The TEE decrypts its encrypted device share and combines it with the auth share to reconstruct the wallet’s private key.
- The key is used temporarily in-memory for cryptographic signing.
- The transaction signature is returned to your application.
Privy also supports broadcasting the signed transaction to the blockchain, directly from the API.
Protecting code deployments to the trusted execution environment
Privy enforces strict controls of the code deployments within the trusted execution environment. Code deployed to the TEE undergoes extensive review and security controls, including strict multi-party approvals and hardware security key requirements.
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, security scanning, and signing requirements. This process is regularly audited and monitored to prevent unauthorized modifications.