Building secure, verifiable blockchain key management on AWS Nitro Enclaves at Turnkey

Private key management remains one of the most challenging security aspects of building Web3 and broader financial applications. In blockchain systems, every transaction requires a cryptographic signature produced by a private key, and whoever possesses those keys controls the associated assets. This means a single compromise can result in immediate, irreversible loss of funds. Traditional approaches force developers into difficult tradeoffs: fragile Do-It-Yourself (DIY) infrastructure, opaque custodial services, or complex multi-party computation systems. Turnkey built a verifiable key management system on AWS Nitro Enclaves that provides enclave-isolated key generation, attestable operations, and policies that serve as access controls. This architecture gives developers strong, verifiable security guarantees with dramatically lower operational overhead.

The key management challenge

Developers building Web3 and broader financial applications face a fundamental constraint: they need secure transaction signing without ever handling raw private keys or seed phrases. The moment a private key enters application memory or touches disk, it becomes vulnerable to extraction through memory dumps, log files, or compromised infrastructure. Applications need these keys to sign transactions, authenticate users, and manage digital assets, introducing a tension between security and usability. Historically, teams navigated this tradeoff through approaches that each carried significant limitations. Building custom key management infrastructure meant taking on significant security responsibility and compliance overhead. Outsourcing to third-party custodians introduced dependencies that limited visibility and control. More advanced approaches like threshold signatures or multi-party computation reduced single points of failure, but added substantial engineering complexity and operational risk. Each approach shifted the tradeoff, without eliminating it. Turnkey removes this tradeoff. By using Nitro Enclaves to create a verifiable key management system, it ensures private keys are never exposed, while still enabling secure, seamless transaction signing in production.

Architecture: Enclave-native key management

Nitro Enclaves are highly constrained compute environments that support cryptographic attestation to verify the enclave’s identity and ensure that only authorized code is running. Nitro Enclaves achieve isolation through a combination of hardware and software mechanisms, including the Nitro Hypervisor and purpose-built hardware. They have no persistent storage, no interactive access, and no external networking.

Turnkey treats Nitro Enclaves as the foundation for all cryptographic operations. All security-critical services, including key generation, signing, and the policy engine, are deployed inside enclaves. Raw key material is never exposed outside the enclave boundary, including to Turnkey’s own infrastructure.

Rather than being tied to an external Key Management Service (KMS) or symmetric key service, raw key material is protected by the enclave’s hardware isolation itself: private keys are decrypted only inside the enclave at the moment of use, and any key ciphertext persisted to the database is encrypted using a symmetric key derived from the enclave’s Quorum Key – a master secret that exists only inside the enclave boundary and is never exported to the host or any external system.

Turnkey Infrastructure

Key generation and storage

Turnkey uses a hierarchical deterministic (HD) wallet model. When a wallet is created, the Signer enclave generates a single wallet seed (mnemonic) using secure entropy from the Nitro Security Module (NSM). From that seed, virtually unlimited child key pairs can be derived on demand using standard BIP-32/BIP-44 (Bitcoin Improvement Proposal) derivation paths (e.g., m/44’/60’/0’/0/0 for Ethereum). New keys are not generated for every transaction – instead, a stable key pair is derived deterministically from the wallet seed and a specified account path, and that derived key is used to sign each transaction request against that account.

The wallet seed itself is never stored in plaintext. After generation inside the Signer enclave, the seed is encrypted under a symmetric key derived from the Quorum Key and the resulting ciphertext is persisted to Turnkey’s primary and disaster recovery databases. At signing time, the coordinator fetches the ciphertext from the database, and the enclave decrypts it entirely within its boundary, re-derives the appropriate child key from the path, performs the signature, and then discards the raw key material. No plaintext key material ever leaves the enclave.

Key lifecycle and deployment

When a developer requests a transaction signature through Turnkey’s API, the request flows through multiple specialized enclave applications, each with a distinct role.

The Signer enclave generates keys using secure entropy from the connected NSM, and performs all signing operations entirely within the enclave trust perimeter, never exposing raw keys.
The Policy Engine enclave handles authentication and authorization using a flexible policy language (described in detail below).
The Parser enclave extracts metadata from unsigned transactions to enrich policy decisions.
The Notarizer enclave authenticates organizational data before other enclave applications act on it, ensuring data passed into enclaves hasn’t been tampered with and enabling an end-to-end verifiable audit trail.
The TLS Fetcher enclave bridges web2 authentication to Turnkey verifiably, and is the only enclave with controlled external connectivity, using an additional, dedicated vsock.

Inter-Enclave communication and attestation-based trust

A natural question is whether these enclave applications simply trust one another by virtue of running on the same host. They do not. Turnkey treats the host VM and all non-enclave infrastructure as potentially compromised components. Enclave-to-enclave requests are mediated through vsock (the only available channel) and each application is independently attested at boot via the NSM. When one enclave application needs to invoke another – for example, when the Policy Engine needs to pass an authorization decision to the Signer – the receiving enclave authenticates the caller by verifying message signatures against a known Quorum Public Key. For example, the Signer trusts messages from the Policy Engine because it knows the Policy Engine’s Quorum Public Key – passed in as a boot argument and verified by virtue of being present in the QOS manifest. This authentication scheme ensures that even if a non-enclave process on the host were to impersonate an enclave service over vsock, it would fail signature verification and be rejected when the enclave application verifies the cryptographic signatures over the provided inputs.

Developers interact with Turnkey through REST APIs and SDKs available in TypeScript, Python, Go, Rust, and Swift. A Coordinator service routes requests to the appropriate enclave applications based on the operation type.

Enclave attestation and verification

Remote attestation is the mechanism by which an enclave can cryptographically prove to a remote verifier what software it is running and that it hasn’t been tampered with. When an enclave boots, the NSM observes the launch process and records cryptographic measurements, hashes of the enclave image, the kernel, and the boot filesystem, in a structure called Platform Configuration Registers (PCRs). These measurements are then signed by the NSM to produce an attestation document.

The attestation message uses Concise Binary Object Representation (CBOR) encoding and contains the following, as defined here:

PCR0 – Hash of the Enclave Image File (EIF)
PCR1 – Linux kernel and initial RAM data hash
PCR2 – Hash of user applications
PCR3 – Hash of the Identity and Access Management (IAM) role of the Nitro host
certificate – X.509 certificate with an enclave-specific public key generated at boot
cabundle – Certificate chain to AWS’s root certificate

The certificate chain ascends to AWS’s root certificate, valid until October 28, 2049.

The following is the parsed Nitro Enclaves root certificate. Note the Not After field, which shows this root of trust remains valid until 2049, providing long-term stability for the attestation chain:

$ openssl x509 -in root.pem -text -noout

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

f9:31:75:68:1b:90:af:e1:1d:46:cc:b4:e4:e7:f8:56

Signature Algorithm: ecdsa-with-SHA384

Issuer: C = US, O = Amazon, OU = AWS, CN = aws.nitro-enclaves

Validity

Not Before: Oct 28 13:28:05 2019 GMT

Not After : Oct 28 14:28:05 2049 GMT

Subject: C = US, O = Amazon, OU = AWS, CN = aws.nitro-enclaves

(...etc)

Anyone can verify that an enclave certificate originates from Amazon by walking this chain, transferring trust from Amazon’s root key to the enclave-specific key that signed the attestation document. Attestation signatures use P-384, a NIST-defined scheme from Federal Information Processing Standards (FIPS) 186-4.

Quorum deployment and the provisioning flow

Running verified software in an enclave is only half the story. Turnkey also needs a secure way to bootstrap enclave applications with the secrets they need to operate, and to ensure no single person at Turnkey can do so unilaterally.

Each enclave application is configured with a Share Set: a group of operators who each hold a share of a master secret called the Quorum Key. When an enclave boots, it waits to receive key shares from members of the Share Set over its vsock connection. Only once a threshold number of shares are submitted does the enclave reconstruct the Quorum Key and launch the application.

Turnkey actively uses remote attestation during this provisioning flow. After deploying a new release, operators each independently build the enclave software themselves and verify that the PCR measurements they derive match what the NSM reports in the attestation document. Only after confirming this match do they post their key share into the enclave. This means no single engineer at Turnkey can alter or deploy an enclave, or reconstruct core secrets, the quorum requirement enforces distributed accountability.

Reproducible builds and QuorumOS

The foundation for all of this is QuorumOS (QOS): Turnkey’s minimal, immutable Linux unikernel engineered for high-security enclaves. Unlike general-purpose Linux distributions, a unikernel runs only the software it needs, substantially reducing the attack surface available to an attacker. QuorumOS provides the initialization and attestation framework for running enclave applications, and integrates directly with the NSM for secure entropy and time.

Crucially, QuorumOS and all Turnkey enclave artifacts are built deterministically, meaning the same source code always produces the exact same binary output. This is powered by StageX, a custom build system that guarantees one-to-one, immutable relationship between human-readable source code and the resulting machine-executable artifacts. StageX distributes packages as Open Container Initiative (OCI) container definitions and it’s fully source code bootstrapped (from a trusted 181-byte assembly seed) to eliminate any trust in toolchains.

Because QuorumOS builds are reproducible, anyone can download the QuorumOS source code, build it locally, and verify that the hash they produce matches the PCR measurements in a live enclave’s attestation document. What you read in the source is provably what runs inside the enclave.

Turnkey verified: Boot proofs in practice

Turnkey exposes this verification capability publicly through Turnkey Verified, a feature available in the Turnkey dashboard and Embedded Wallet Kit that lets anyone inspect the cryptographic proofs produced by Turnkey’s infrastructure.

Each proof is a signed JSON payload produced inside the enclave and exposed through the Turnkey Verified API. Two representative proof types illustrate the system’s guarantees:

1) Address derivation proof payload

This proof confirms that a wallet address was derived deterministically inside the enclave from the specified wallet seed and derivation path, without the underlying private key ever leaving the trust perimeter:

{
"type": "APP_PROOF_TYPE_ADDRESS_DERIVATION",
"timestampMs": "1758909116",
"addressDerivationProof": {
    "organizationId": "your-organization-id",
    "walletId": "your-wallet-id",
    "derivationPath": "m/44'/60'/0'/0/0",
    "address": "0x61f4Ec0630DD50F1393cbDB60e5ccA1ed98f5100"
}
}

2) Policy outcome proof payload

This proof confirms that the Policy Engine enclave evaluated a signing request against the organization’s policy rules and produced an authorization decision entirely within the enclave:

{
"type": "APP_PROOF_TYPE_POLICY_OUTCOME",
"timestampMs": "1758909116",
"policyOutcomeProof": {
    "organizationId": "your-organization-id",
    "outcome": "OUTCOME_ALLOW",
    "decisionContextDigest": "your-decision-context-digest",
    "organizationDataDigest": "your-organization-data-digest",
    "parentOrganizationDataDigest": "your-parent-organization-data-digest"
}
}

Each of these proves that a specific enclave is running in a legitimate Nitro environment with the exact QuorumOS configuration and application binary that Turnkey claims, and confirms that enclave actually processed the specific request. All of this is verifiable without trusting Turnkey’s operational assertions.

Threat model and trusted computing base

Turnkey’s threat model treats only enclave applications and their Share Sets as trusted. All other components, the host VM, the Coordinator, the database, and even AWS infrastructure outside the Nitro system, are considered potentially compromised. This is achievable because of Nitro Enclaves’ isolation guarantees:

No persistent storage: The enclave is stateless; volatile memory is cleared on every restart
No network access: The only connection is the vsock interface to the host
Hardware-rooted entropy and time: Provided by the NSM, independent of the host

Even if an attacker fully compromises the host system, they cannot extract keys from the enclave and cannot modify enclave code. The vsock link is the only way in or out.

Real-world use cases

This architecture translates directly into concrete deployment scenarios that Turnkey customers rely on in production today:

Embedded consumer wallets: Fintech and consumer apps provision one wallet per end user at sign-up. Because keys never leave the enclave, the application developer cannot unilaterally move a user’s funds – custody genuinely belongs to the user. Policy rules enforce spending limits, block suspicious addresses, and require multi-factor approval, all enforced inside the enclave rather than in application code that could be bypassed.
AI agent transaction management: Autonomous agents increasingly need to hold and transact digital assets on behalf of users or protocols. Turnkey’s architecture lets operators constrain what an agent can sign – by asset type, counterparty, or transaction size – via the Policy Engine, without giving the agent or its host process direct access to private keys. Even a fully compromised agent runtime cannot exfiltrate funds outside the policy envelope.
Enterprise payments and smart contract deployments: Teams running high-value payment operations or deploying smart contracts need audit trails and separation of duties without operational fragility. Turnkey’s quorum-controlled provisioning and attestation-backed audit trail mean every signing event is cryptographically verifiable, supporting both internal compliance and external audit requirements.

Conclusion

Turnkey has operated in production for almost four years, securing millions of wallets and private keys across embedded wallets, smart contract deployments, payments, treasury management, and AI agent deployments.

For developers building financial applications, Turnkey provides a path to integrate secure transaction signing without ever handling raw private keys or seed phrases. APIs and SDKs abstract away the complexity of enclave management, attestation verification, and policy enforcement, while the underlying architecture ensures security guarantees hold even under sophisticated attacks. The verifiable nature of the system means security is not based on trusting Turnkey as an operator. Customers can independently verify what runs in every enclave by obtaining a Boot Proof through the Turnkey Verified feature and comparing PCR measurements against a locally-built QuorumOS artifact. This transforms key management from an opaque service requiring blind trust into a transparent system backed by cryptographic proofs. As more applications require secure key management for digital assets, authentication, and cryptographic operations, the model that Turnkey built on Nitro Enclaves establishes a new standard for how these systems should be built. The combination of hardware isolation, reproducible builds, quorum-controlled provisioning, and remote attestation creates infrastructure that is both more secure and more transparent than previous approaches.

To start building with verifiable key management, explore Turnkey’s developer documentation and learn more about Nitro Enclaves.

AWS Web3 Blog