Trusted Execution Environments for Trading: AWS Nitro, Intel SGX, and AMD SEV Compared

I have built production signing infrastructure on AWS Nitro Enclaves. I have evaluated Intel SGX extensively for on-premise key management. I have read more AMD SEV-SNP documentation than any reasonable person should. The practitioner’s guide to Trusted Execution Environments for trading infrastructure does not really exist - the papers are academic, the blog posts are marketing, and the documentation assumes you already understand the hardware. This post is the one I needed three years ago.

The stakes are real. Every major crypto custody breach in the last decade has one thing in common: the private keys were accessible to software running on the same host. AWS has access to EC2 instance memory. A compromised admin account can dump a running process. A malicious insider can attach a debugger. None of these threat vectors require breaking cryptography - they just require access to a machine. TEEs exist to make “access to the machine” insufficient.

Here is what the three major TEE platforms actually do, how they differ, where each is the right choice, and the specific numbers we measured at ZeroCopy.

What a TEE Is and Why Trading Needs It

A Trusted Execution Environment is a hardware-enforced isolated execution context whose memory cannot be read or modified by software running outside the enclave - including the operating system, the hypervisor, and the cloud provider’s infrastructure. The guarantee is backed by hardware: the CPU encrypts enclave memory in a way that only the CPU itself can decrypt, using keys burned into hardware during manufacturing.

For trading infrastructure, this matters in three specific ways.

Key isolation. If your signing keys live inside a TEE, an attacker who compromises your EC2 instance cannot extract them. The keys can be sealed to the enclave’s measurement, meaning they can only be decrypted by an enclave running the exact same code. Changing the enclave code breaks the seal.

Attestation. Every major TEE produces a signed attestation document: a cryptographically verifiable statement of exactly what code is running inside the enclave. The attestation document is signed by a certificate chain rooted in hardware - on Nitro, by AWS’s root CA; on SGX, by Intel; on SEV-SNP, by AMD. An auditor, LP, or regulator can verify that your signing infrastructure is running the code it claims to run without any access to the infrastructure itself.

Provable code execution. Combine isolation and attestation and you get something powerful: the ability to prove that a specific computation happened in a specific way. For trading firms facing regulatory scrutiny, or institutional LPs who want to verify that risk limits are actually enforced, this is the primitive that makes audit credible rather than theatrical.

TEEs are not magic. They do not protect against vulnerabilities in the enclave code itself - a buffer overflow inside the enclave is still exploitable. They do not protect against side-channel attacks, which are a real and ongoing area of research. But they raise the cost of key extraction and computation tampering dramatically, from “root access to the instance” to “physical access to the hardware with specialized tools.”

AWS Nitro Enclaves

Nitro Enclaves are the TEE implementation that matters most for cloud-native trading infrastructure. Since you are almost certainly running on AWS, this is the one to understand first.

Architecture

An AWS Nitro Enclave is a separate virtual machine created from a subset of the parent EC2 instance’s vCPUs and memory. It runs inside the Nitro Hypervisor, isolated from the parent instance by hardware. The isolation properties are specific and worth stating precisely:

• The enclave has no network interface. No TCP/UDP/ICMP from outside the host.
• The enclave has no persistent storage. No EBS, no S3 mounts, no local disk.
• The only communication channel between the parent instance and the enclave is a vsock socket.
• The parent instance cannot attach a debugger to the enclave.
• AWS operator access is explicitly excluded from the enclave memory space.

The vsock channel is important because it means every byte of external data - market data, keys, signing requests - must transit a single serialized connection. This is both a security feature and a performance constraint. We will return to the performance implications.

The PCR Registers

Nitro attestation is built around a set of Platform Configuration Registers (PCRs). These are hash registers, conceptually similar to TPM PCRs, that accumulate measurements of what is running inside the enclave. The attestation document includes all PCR values, signed by AWS’s root CA for Nitro.

Understanding which PCR measures what is necessary for designing a sealed-key system:

PCR0 measures the enclave image file (EIF) - a hash of the entire enclave container image, including all code, libraries, and configuration baked in at build time. Two EIFs that produce the same binary artifact will produce the same PCR0. This is the register you seal signing keys against: “this key can only be used by code whose image hash is PCR0 = X.”

PCR1 measures the Linux kernel and boot parameters inside the enclave. This changes when you update the kernel version, which matters if you are running enclaves with explicit kernel pinning for compliance.

PCR2 measures the application code and configuration loaded from the enclave’s init process. On a Nitro Enclave running a custom application, PCR2 covers the application binary and its startup arguments.

PCR3, PCR4, PCR8 measure the IAM role ARN, instance ID, and enclave image file certificate respectively. These allow you to create KMS key policies that restrict decryption to a specific enclave running on a specific instance type launched by a specific role.

The practical design pattern: you generate a sealing key, use KMS to encrypt it with a key policy locked to PCR0 + PCR3, and store the encrypted blob in S3. The enclave starts, presents its attestation document to KMS, KMS verifies PCR0 matches the policy, and decrypts the blob. If someone deploys a modified enclave - even one character different in the code - PCR0 changes and KMS refuses. No human intervention required; the cryptography enforces it.

KMS Integration

The KMS integration is what makes Nitro Enclaves genuinely practical for production key management. The kms:Decrypt call from inside the enclave includes the attestation document as a parameter. KMS parses the attestation, verifies the PCR values against the key policy, and either decrypts or refuses. The round-trip from inside the enclave over vsock to the parent instance’s network stack to KMS and back takes roughly 8-12ms in us-east-1 on a low-contention day.

This 8-12ms is for key unsealing at startup, not for signing. Once the enclave has unsealed its key material, signing operations happen entirely inside the enclave with no KMS involvement. Our measured p50 signing latency on a c6i.2xlarge with a dedicated Nitro Enclave running ECDSA P-256 is 42µs. p99 is 87µs. The vsock round-trip from the parent to the enclave and back adds roughly 80-120µs overhead, making the end-to-end signing latency from application request to signed response about 130µs in the typical case.

What Nitro Does Not Provide

No persistent state. If the enclave crashes and restarts, it must re-unseal its keys from KMS. This takes 8-12ms - acceptable for a restart scenario, but you need to handle it in your request routing layer.

No direct networking. If your signing enclave needs to call a blockchain RPC endpoint or an external API, those calls must be proxied through the parent instance via vsock. Latency adds up: vsock hop (~100µs) + network call + vsock hop back. For signing operations where the signed payload is self-contained, this does not matter. For attestation workflows that require external verification, it does.

Limited to AWS. Nitro Enclaves only exist on EC2. If you are running on Azure, GCP, Equinix, or bare metal, this option is not available.

Intel SGX

Intel SGX (Software Guard Extensions) is the oldest and most mature TEE technology. SGX was introduced with Skylake processors in 2015 and has gone through multiple generations. It operates at a fundamentally different level than Nitro: rather than isolating a VM, SGX isolates a memory region within a single process.

Architecture

An SGX enclave is a region of memory called the Enclave Page Cache (EPC) that is encrypted by the CPU. Code and data inside the EPC are protected from access by any other software on the system, including the OS kernel and hypervisor. The hardware encrypts all EPC pages with a key that is ephemeral - it is generated at boot and destroyed on power-off, meaning physical memory extraction does not reveal enclave contents.

The programming model requires explicitly structuring your application to separate trusted code (inside the enclave) from untrusted code (outside). All transitions between trusted and untrusted code go through a defined interface: ecall (trusted function called from untrusted code) and ocall (untrusted function called from trusted code). Every ocall is a potential trust boundary violation - if your enclave calls out to the OS for memory allocation, the OS can potentially observe call patterns even if not content.

EPC Memory Limits

The EPC size is a fundamental constraint of SGX. On SGX1 (first-generation, most common in cloud environments), the EPC is limited to 128-256MB across all enclaves on the host. Once EPC is exhausted, the SGX driver begins encrypting and paging out enclave pages to regular DRAM - a process called “EPC swapping” that is catastrophically slow (50-100x slower than in-EPC access).

SGX2, available on Xeon Sapphire Rapids and later, extends this significantly. The EPC can be up to 512GB in some configurations, effectively eliminating the memory constraint for typical applications. The catch is that SGX2-capable instances are not widely available in cloud environments yet. AWS does not offer SGX2 instances. The only reliable way to get SGX2 today is bare metal with a recent Xeon.

For a signing application that holds a few hundred bytes of key material and performs arithmetic operations, SGX1’s memory limits are not a problem. For a strategy engine that needs to hold large datasets in protected memory, SGX1 is impractical.

Remote Attestation: DCAP

Intel’s modern attestation mechanism is DCAP (Data Center Attestation Primitives), which allows organizations to run their own attestation infrastructure rather than depending on Intel’s attestation service (IAS). DCAP is the right choice for production deployments.

The DCAP attestation flow:

1. The enclave calls sgx_get_quote() to generate a Quote - a signed summary of the enclave’s measurement, including the MRENCLAVE (hash of enclave code and initial state) and MRSIGNER (hash of the key that signed the enclave).
2. The Quote is sent to your DCAP verification service, which holds the Provisioning Certification Key (PCK) certs from Intel’s PCK Cert Service.
3. The verifier checks the PCK cert chain and confirms the Quote is valid, then extracts MRENCLAVE and MRSIGNER for comparison against your expected values.

MRENCLAVE is the SGX equivalent of PCR0 in Nitro - it uniquely identifies the enclave binary. Sealing data to MRENCLAVE means the data can only be accessed by an enclave with that exact code hash.

SGX in Practice for Trading

SGX is the right choice for on-premise key management when you are running your own hardware. The programming model is more demanding - you need to restructure your application explicitly for trusted/untrusted separation - but the TCB (Trusted Computing Base) is smaller than Nitro. With Nitro, you trust AWS’s Nitro Hypervisor, their attestation CA, and their PCR measurement process. With SGX, your trust root is Intel’s manufacturing process and the CPU itself.

The EPC memory constraint makes SGX unsuitable for running large computations inside the enclave. Signing operations and key management fit easily within 256MB. A full trading strategy does not.

AMD SEV-SNP

AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) takes the opposite architectural approach from SGX. Rather than protecting a memory region within a process, SEV-SNP protects an entire virtual machine.

Architecture

SEV-SNP encrypts all VM memory with a key unique to that VM, stored in the AMD Secure Processor (ASP). The hypervisor manages the VM but cannot read its memory - the ASP mediates all key operations, and the hypervisor only ever sees ciphertext. “Secure Nested Paging” specifically means that the hardware-enforced page tables prevent the hypervisor from mapping VM memory pages into its own address space, closing the most obvious attack vector.

The result is that an entire VM can run with the same isolation guarantees that Nitro provides, but the application code does not need to be modified. Any VM that can boot in a normal hypervisor can boot as an SEV-SNP confidential VM. This is the killer feature for migration scenarios: if you have an existing application you cannot restructure for SGX, SEV-SNP protects it with minimal changes.

Attestation

AMD SEV-SNP attestation works through the VCEK (Versioned Chip Endorsement Key) certificate. Each AMD CPU generates an attestation report signed by the VCEK, which is in turn certified by AMD’s certificate hierarchy. The attestation report contains:

• A measurement of the guest VM’s initial state (equivalent to MRENCLAVE in SGX)
• The AMD firmware version and TCB version
• A nonce you provide, preventing replay attacks

The attestation report is not as granular as Nitro’s PCR-based system - there is no separate measurement for kernel vs application. But for the primary use case (prove that this exact VM image is running on real AMD hardware with no hypervisor tampering), it is sufficient and straightforward.

SEV-SNP Availability

AMD SEV-SNP is available on AMD EPYC Milan (3rd gen) and later processors. Cloud availability is limited but growing: Google Cloud’s Confidential Computing instances use AMD SEV (earlier versions), Azure’s Confidential VMs support SEV-SNP on specific instance families, and AWS has no SEV-SNP offering (they have Nitro, which is their proprietary approach). The most reliable path to SEV-SNP today is bare metal with EPYC Milan or Genoa processors.

For ZeroCopy’s on-premise deployments, SEV-SNP is the preferred choice for compute that runs in a VM but cannot be restructured for SGX’s programming model. The ability to lift and shift an existing signing service into a confidential VM without code changes is valuable.

Comparison Table

ZeroCopy’s Architecture Decision

ZeroCopy uses Nitro Enclaves for cloud-hosted signing. The KMS integration is genuinely excellent - PCR-locked key policies mean our signing keys are cryptographically sealed to a specific enclave image, and changing the enclave code requires a deliberate key migration process. The attestation document served by the enclave is the primary artifact in our audit trail.

For clients who run on-premise infrastructure where AWS is not an option, SEV-SNP is the preferred path for full-VM isolation of existing services, and SGX for new services that can be written to the SGX programming model from the start.

Benchmark Reality

Numbers from ZeroCopy’s production Nitro Enclave deployment on c6i.2xlarge instances:

Operation                          p50        p99       p999
────────────────────────────────────────────────────────────
ECDSA P-256 sign (in-enclave)     42µs       87µs      145µs
Key unseal via KMS (startup)      8.3ms      14.2ms    28ms
vsock round-trip overhead          80µs       118µs     220µs
End-to-end sign (app → response)  127µs      210µs     380µs

Comparison baselines:
AWS KMS sign                      ~160ms     ~350ms    (highly variable)
Traditional HSM (nCipher)         ~3ms       ~8ms
Fireblocks (API round-trip)       ~180ms     ~400ms

The 3,095x advantage over AWS KMS on p50 is the headline number, but the more important figure is variance. AWS KMS p99 at 350ms means that once in every hundred signing operations, you wait a third of a second. At 1,000 trades per day, that is 10 trades per day where your signing latency is over 350ms. In a live market, those 10 trades are statistically your worst fills.

Determinism is worth as much as raw speed. A Nitro Enclave running on a dedicated core with vsock transport has predictable, bounded latency. KMS does not.

When TEEs Are Not the Answer

TEEs add operational complexity. The enclave must be rebuilt and redeployed for any code change. Key migration when PCR values change requires careful coordination. The vsock communication model requires explicit proxy infrastructure. Attestation document verification must be implemented correctly or it provides false confidence.

If your threat model is primarily “my laptop gets stolen” or “I forget to rotate API keys,” TEEs are not the right tool. They are overkill for hot wallet risk at retail trading scales.

If your threat model includes “a compromised cloud instance,” “an insider with root access,” “a regulator who needs cryptographic proof of what code ran,” or “an institutional LP who needs to verify risk limits are enforced” - TEEs are not optional. They are the only technology that addresses these threats at the hardware level.

The next post in this series covers one of the most powerful applications of TEE-based attestation: protecting trading strategy IP while still proving to investors that the strategy is what you described.