Skip to content

AWS 2026-10-27 Tier 1

Read original ↗

How Anchorage Digital and Turnkey verify code with AWS Nitro Enclaves

Summary

An AWS Architecture Blog post, co-written with Anchorage Digital (a federally regulated digital-asset bank) and Turnkey (a verifiable key-management provider), describing VisualSign — an open-source Rust, cross-chain transaction parser that runs inside AWS Nitro Enclaves on Turnkey Verifiable Cloud and returns human-readable transaction breakdowns together with attestation-backed proof of which software produced them. The motivating problem is blind signing: wallets can't natively decode complex DeFi transactions, so users approve hex payloads that hide malicious token approvals or transfers, and existing simulation/decoder services must be trusted without any way to verify what code they ran. The architecture answers two required guarantees — correctness (the parser is the exact audited code) and integrity (output not tampered with in transit) — by combining reproducible builds, enclave-hosted computation, and Nitro attestation documents whose PCR measurements a wallet compares to build-derived values. The post then generalizes the design into an attestation-gated access pattern (patterns/attestation-gated-key-release): an HSM releases key material only to an enclave whose attestation verifies, so proof of what code is running replaces network identity, API keys, or operator trust as the access credential — and the attestation becomes a machine-verifiable contract between a domain team (blockchain parsing) and a security team (HSM policy).

Key takeaways

  1. The trust problem is "did the service run the code it claims?" — contractual trust, network perimeters, and reputation give no cryptographic answer. A transaction parser needs correctness (exact, unmodified audited code) and integrity (output unmodified between parser and wallet). (Source: sources/2026-10-27-aws-how-anchorage-digital-and-turnkey-verify-code-with-aws-nitro-enclaves)

  2. Request path (5 steps). Wallet → Turnkey API → a Nitro-Enclave-capable EC2 instance running QuorumOS (Turnkey's open-source enclave OS) + the VisualSign Parser binary → parser emits structured JSON → enclave signs the response with an ephemeral P-256 key and requests a Nitro attestation document from the Nitro Hypervisor → wallet verifies attestation + signature. Anchorage "doesn't need to trust Turnkey."

  3. Reproducible builds make PCRs a stable verification policy. The attestation carries Platform Configuration Registers (PCRs) — measurements of enclave image, kernel, and application. Because the build is byte-identical regardless of who builds it or where, PCR values are deterministic: "the trusted values stay constant across rebuilds and verification policies never need to be updated," and any third party can independently confirm the enclave runs the expected QuorumOS version and the unmodified parser. (concepts/reproducible-builds)

  4. Four Nitro Enclave properties the trust model depends on: (a) vCPU + memory isolation from the parent instance via the same Nitro Hypervisor that isolates EC2 instances; (b) no persistent storage, no network interface, no DNS, no metadata service — only a local vsock channel to the parent; (c) hypervisor-signed attestation documents chained to the AWS Nitro Attestation PKI; (d) no single AWS, Turnkey, or Anchorage operator can access data in the enclave. (systems/nitro, concepts/trusted-execution-environment)

  5. Attestation verification is easy to get wrong. The document is a COSE Sign1 structure over CBOR whose payload holds an X.509 cert chain, PCRs, and optional UserData / PublicKey / Nonce. Correct verification = parse CBOR → validate COSE signature → walk the chain to the AWS Nitro root (concepts/chain-of-trust) → check expiry → compare PCRs, with clear errors at each step.

  6. awsnitroverifier (Go) — two-tier error handling as an API design choice. Malformed input surfaces as err != nil; validation failures as result.Valid == false, each with a specific reason (PCR mismatch, expired cert, chain failure) rather than a generic "verification failed." Built-in PCR validation, direct access to UserData/PublicKey/Nonce, root-cert fingerprint and chain-trust status, an offline/test mode for CI/CD without a live enclave, and a migration guide from the widely used nitrite library.

  7. Layered verification levels you can adopt incrementally (via visualsign-turnkeyclient, built on awsnitroverifier): (1) basic P-256 signature check (a key in Turnkey's infra signed it); (2) boot attestation with PCR validation (image + config match); (3) full QuorumOS manifest verification including the specific application binary hash. The split between a focused attestation library and an application client lets non-blockchain users drop the blockchain dependencies.

  8. Attestation as an access credential. At Anchorage, HSMs hold key material; the parser runs in a separate enclave; the HSM grants access based on verified attestation — "not based on trusting the network, the operator, or the host machine." The principle: keep the computation away from the sensitive data and use attestation to bridge the gap. (patterns/attestation-gated-key-release)

  9. Attestation as an organizational contract. Ownership splits cleanly: blockchain domain experts maintain the parser (Ethereum opcodes, Solana instruction formats, DeFi semantics) with no access to key material; the security/infra team owns attestation verification, HSM policy, and access control without needing to understand Solana's account model. The attestation is "the machine-verifiable contract between the two teams." (concepts/separation-of-concerns)

  10. The pattern is not crypto-specific. Proposed non-Web3 uses: sanctions screening / AML in an enclave from a reproducible image (proof the audited screener processed the data); diagnostic models over patient data in an enclave with no storage or network (operator can't exfiltrate); any sensitive operation relying on third-party libraries, pinned to a reproducible build. (concepts/confidential-computing)

Systems / concepts / patterns extracted

Architecture

wallet ──raw tx──▶ Turnkey API ──▶ EC2 parent instance
                                     │ vsock (only channel)
                                     ▼
                               Nitro Enclave: QuorumOS + VisualSign Parser
                                 1. parse → JSON
                                 2. sign w/ ephemeral P-256 key
                                 3. NSM → attestation doc (PCRs, PublicKey, UserData, Nonce)
wallet ◀──JSON + sig + attestation──┘
  verify: COSE sig → X.509 chain → AWS Nitro root → expiry → PCRs == reproducible-build values

Generalized: untrusted input → enclave app → signed bundle + attestation
             → HSM verifies attestation → releases key material to that software only

Operational details

  • Chains supported at time of writing: Ethereum + L2s (Arbitrum, Optimism, Base, Polygon), Solana, Sui, Tron.
  • Example: a Uniswap Universal Router fixture of 2,470 hex characters decodes into Permit2 approval → V2 swap (amounts, min outputs) → fee payment → WETH unwrap, each with explicit addresses/amounts/expiries.
  • Response signing key: ephemeral P-256; enclave I/O: vsock only.
  • Collaboration began after Turnkey's whitepaper (January 2025).

Caveats

  • Partner/architecture post co-written with the vendors; no latency, throughput, fleet size, or failure-mode numbers are given.
  • TVC is in private beta as of writing.
  • The post doesn't address TEE side-channel risk or how the PCR allowlist / manifest is published and rotated beyond "values derived from reproducible builds" — compare the transparency-ledger layer in systems/whatsapp-private-processing and systems/confidential-federated-compute.
  • "No single operator can access" is an AWS/vendor claim, not independently demonstrated here.

Source

Last updated · 854 distilled / 2,448 read