Trusted execution environments (TEEs)

Privy provides two types of secure execution environments that protect sensitive operations through independent security boundaries: 1) on the user's device and 2) via TEEs in the server. Each environment ensures that private keys are never stored in complete form and are only temporarily reconstructed when needed.

For direct API access to wallet infrastructure, Privy enables secure server-side wallet actions via trusted execution environments (TEEs).

TIP

Privy wallets are non-custodial and have a fully programmable control model. Privy's flexible configuration enables the full spectrum from user-custodial wallets to powerful service-level controls.

About 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 reconstitution 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.

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

1. Enclave (device) share, also referred to as the TEE share, which is secured directly by the trusted execution environment. This share is encrypted with the enclave's public key, and can only be decrypted within the TEE.
2. Auth share, which is encrypted and stored by Privy. This share is accessible only with valid authentication, 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.

TIP

Only the TEE can decrypt the enclave share and combine it with the auth share to reconstitute the wallet and execute actions.

Key management operations

Creating a wallet

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.

Signing a transaction

Two shares must be present to reconstruct the private key. During regular operation, Privy reassembles the wallet using a device share and auth share.

In other words, when signing a transaction:

1. Your app makes a POST request to the Privy API with the appropriate bearer token (typically the Privy app secret) and an authorization key signature.
2. Privy's backend authenticates the bearer token. If the request is valid, the request is forwarded to the TEE, along with the auth share.
3. The TEE verifies the authorization signature from your request against the authorization public key.
4. The TEE decrypts its encrypted device share and combines it with the auth share to reconstruct the wallet's private key.
5. The key is used temporarily in-memory for cryptographic signing.
6. The signature is returned to your application.

Privy also supports broadcasting the signed transaction to the blockchain, directly from the API.