Institutional Vault combines threshold Multi-Party Computation (MPC) with Trusted Execution Environments (TEEs) on each policy node. Together they provide defense in depth: the private key is never held in one place, and each key share is protected while stored, while moved between nodes, and while used for signing.

For operational lifecycle diagrams (key generation, storage, signing), see Key Management Lifecycle. For MPC signing protocols and curves, see Cryptographic operations (MPC signing).

Trusted execution environments

Each policy node can run inside a confidential execution environment that acts as a virtual HSM: sensitive work happens in hardware-isolated memory with no interactive operator access.

AWS Nitro Enclaves

On AWS, policy nodes use the Nitro System. Unlike traditional virtualization where a general-purpose hypervisor manages CPU and memory (leaving a privileged host path), Nitro uses hardware partitioning.

Memory encryption and isolation

When a policy node runs in a Nitro Enclave, the Nitro hypervisor allocates dedicated CPU and memory. There is no SSH or general network access except via a secure local vSock channel to the parent instance.

• No administrative access: An AWS account operator or root user on the parent EC2 instance cannot read enclave memory. Memory is encrypted with instance-specific keys handled by the Nitro Card.
• Cryptographic attestation: The enclave produces a signed attestation report proving that an approved, unmodified binary is running. Share-decryption keys are released from AWS KMS only when attestation policy matches approved measurements, so plaintext share material is available only inside attested enclaves.

Azure Confidential Containers

On Azure, all three policy nodes run as Confidential Containers on Azure Container Instances, using AMD SEV-SNP hardware isolation. Each node executes in a hardware-enforced confidential environment. The wallet and supporting services run separately; policy nodes connect over the private network (see Azure deployment process).

• Workload attestation: Approved policy-node software is measured and attested before secrets are released.
• Secure key release: Wrapping keys in Premium Azure Key Vault (HSM-backed) are released only to attested containers that match the approved workload.
• In-container secrets: Sensitive configuration, including material needed to decrypt MPC key shares, is handled only inside the confidential container boundary.

End-to-end protection of key shares

Key shares are encrypted with wrapping keys provisioned through the deployment's cloud KMS (AWS KMS or Azure Key Vault). Sensitive material exported from a policy node remains tied to that KMS and attestation policy; plaintext shares are not written to disk, backups, or logs.

Protection at rest

Shares are encrypted at rest (for example AES-256-GCM with a per-node Master Encryption Key) and stored in each policy node's isolated database. The MEK and share-decryption paths are gated by confidential computing and KMS:

• KMS releases decryption material to a TEE only when policy is satisfied by measurements of the application binary and execution environment.
• When KMS releases a key to an enclave, it can be wrapped with an enclave-specific public key attested by the same measurement mechanism.

This yields hardware-bound storage:

• Encrypted share blobs are useless on another server without the same attested environment and KMS policy.
• Decryption keys exist only in volatile TEE memory and are cleared on restart or termination.
• Access to raw storage or database rows by an infrastructure operator yields only ciphertext, not usable share material.

MPC key shares are generated and used inside enclave boundaries and persisted externally only in encrypted form. Decryption is permitted only inside a TEE whose attestation matches approved Institutional Vault binary measurements.

Protection in transit

During MPC ceremonies, nodes exchange protocol messages over mutual TLS (mTLS). Where deployed with Nitro Enclaves or Azure Confidential Containers, sensitive handling stays inside the TEE boundary, so intercepted network traffic does not expose plaintext shares outside the enclave.

Defense in depth: MPC, TEE, and proactive refresh

Institutional Vault does not rely on a single control. Three pillars reinforce each other:

1. MPC (threshold signing): The private key (for example ECDSA secp256k1 or Ed25519) is never reconstructed in any single location. Signing is computed across distributed shares; full key material does not exist in memory on one node.
2. TEE (confidential computing): Each policy node runs in an isolated execution environment, reducing risk from memory scraping or host-level compromise compared with ordinary cloud VMs.
3. Proactive refresh (resharing): Shares can be rotated mathematically without changing the underlying public key. If an attacker obtains fewer than the threshold number of shares, resharing can invalidate previously exposed material and prevent sub-threshold compromise from accumulating over time.

Under the threshold scheme, fewer than the required number of shares are insufficient to derive the private key or produce valid signatures. TEE isolation and attestation limit export or leakage of shares from each node. An attacker must defeat multiple independently attested environments and multiple encryption layers, not a single device.

Comparison with physical HSMs

Physical FIPS 140-2 Level 3 (or similar) HSMs concentrate key material in one appliance. Institutional Vault's MPC plus TEE model trades that single fortress for distributed cryptography and per-node hardware isolation.

Physical HSMs remain appropriate for some integrations (for example PKCS#11 recovery flows). Institutional Vault uses MPC and TEE for routine custody and signing while supporting optional HSM-backed recovery where configured.

Related documentation

• Security Model - Policy engine and threshold policy enforcement
• Key Management Lifecycle - DKG, encrypted storage, and signing ceremonies
• Institutional Vault Overview - Supported confidential computing providers (section 6)
• Production deployment: Generic install process - Confidential Computing - Operational requirements for policy nodes