Powering programmable crypto wallets at Coinbase with AWS Nitro Enclaves

A crypto wallet is a tool for managing cryptocurrencies, often built using a combination of software and hardware components. Web3 developers need a simple, API-driven way to manage wallets for applications like payments, trading, or in-game economies. Directly managing private keys, the unique identifier to access and control the wallet, creates significant operational overhead and security risks. This diverts developer focus from building their core products.

While developers prefer to offload infrastructure management to a trusted provider, this creates a new challenge. Giving full control to a third-party entity can introduce risks, such as service denial or the potential loss of funds if the provider is compromised. The core problem is how to delegate wallet management without sacrificing security and control over the assets.

Coinbase Developer Platform (CDP) solved this challenge by building the Wallet API, used to create and manage programmatic wallets. The Wallet API gives developers both a simple management experience and robust security, achieved by using AWS Nitro Enclaves. Nitro Enclaves are fully isolated computing environments that protect sensitive data and code. By using enclaves for all cryptographic operations, Coinbase makes sure that private keys are managed securely, isolated even from Coinbase’s own infrastructure. This design allows developers to programmatically manage wallets through a simple API while providing strong assurances that their funds are safe.

This post describes the Wallet API system architecture, threat models, and how Coinbase and AWS partnered to increase enclave throughput by a factor of 10.

Secure key management in Nitro Enclaves

The core of the CDP Wallet API design is the verifiable application running within Nitro Enclaves that can be used to handle sensitive cryptographic operations. Nitro Enclaves provides the service with several key security capabilities including:

• Strong isolation of memory and CPU during execution
• No persistent storage
• No external network access, including DNS, Network Time Protocol (NTP), or metadata services
• Remote verifiable cryptographic attestation to prove the identity of the enclave and the code running within it, without requiring direct access to the enclave.

Communication between the instance and the enclave occurs over a secure local channel (vsock), as shown in the following figure. Even root or admin users on the instance cannot SSH into the enclave.

In Coinbase’s design, cryptographic operations happen only within the enclave. To make sure that no unauthorized entity at Coinbase can access the application running inside the enclave, requests from developers are cryptographically signed and verified by the enclave application. Access to private keys is restricted solely to the developer and the enclave through end-to-end encryption between Coinbase’s developer SDK and the Nitro Enclave.

High-level architecture

Process as shown in the preceding figure:

1. The developer holds an asymmetric key pair used to authenticate with the Secure Signer process inside the enclave. This key is separate from the API authentication key used by Coinbase APIs. This segregation of API authentication from enclave authentication enhances the isolation, auditability and improves the overall security posture.
2. After API authentication and various validations at the API layer, requests are forwarded to the Secure Signer process in the enclave. Each developer request includes a cryptographic signature that is verified within the enclave to authenticate the developer’s identity.
3. The Secure Signer process running inside the enclave performs sensitive operations, including authenticating the developer, private key generation, and transaction signing. Private keys of accounts are encrypted and decrypted exclusively within the enclave.
4. The Secure Signer uses AWS Key Management Service (AWS KMS) keys for encrypting all sensitive data. The enclave connects to AWS KMS using AWS vsock proxy, which is a proxy service that allows the enclave to establish a TLS handshake with AWS KMS. In Coinbase’s design, the only egress the enclave has is to AWS KMS through this proxy.
5. The resulting payload for the developer’s request is sent back to the API layer over vsock, which is then returned to the CDP SDK run from developer’s code.

Deep dive into enclave application

For image build and deployment, the enclave application is packaged in enclave image file (EIF) format to be run inside Nitro Enclaves. The EIF is a packaged binary that includes the application code, OS kernel, and other dependencies. EIFs built with nitro-cli are immutable, helping to ensure deterministic and reproducible builds. This provides us with strong protection against software supply chain attacks.

During enclave initialization, the Nitro hypervisor computes Platform Configuration Registers (PCRs) based on the EIF contents. PCRs are cryptographic measurements to help ensure enclave integrity and allow remote attestation. These PCR values are signed by the nitro hypervisor and can be verified by external parties, such as AWS KMS, to verify the enclave identity. AWS KMS policy conditions can reference these PCRs to restrict access to the specified EIF binary. This helps ensure that the AWS KMS keys in the architecture can only be called from verified code running inside the Nitro enclave.

The Secure Signer that runs inside the enclave is a Rust binary with Foreign Function Interface (FFI) bindings to a fork of AWS Nitro Enclaves SDK for C. This binary performs all sensitive operations on private keys, in addition to the enclave authentication for every request from the developer. The integration with AWS KMS allows the enclave to attach an attestation document to the request, which is then verified by AWS KMS before the request is processed. These APIs are intricate and complex, and thus Coinbase has not ported them to any other language. Instead, Coinbase chose to build FFI bindings to interact with the Nitro Enclave KMS SDK in C from the Secure Signer code written in Rust.

Secure import and export of keys

To give developers full control of their wallets, Coinbase Developer Platform APIs provide a secure way to import and export private keys. By running the Signer process inside a tamper-proof, verifiable compute environment, we were able to open a secure channel between the developer and Coinbase infrastructure. The import and export flows are end-to-end encrypted between the developer’s SDK and the enclave, helping to ensure that private keys are accessible only to the developer or the enclave.

Built-in policy engine

The Secure Signer within the enclave must not blindly sign every authenticated request, because this leaves developers vulnerable if their authentication keys are compromised. To address this, we provide a built-in policy engine with fine-grained permissions that allow developers to govern the behavior of their wallets. The engine enforces rules based on transaction parameters such as destination address and amount. The Secure Signer validates that these rules are evaluated, and customer intent is verified before generating a signature for any transaction. Programmable transaction policies are a big appeal to developers who have witnessed major crypto hacks caused by operational oversights.

Envelope encryption

The Secure Signer uses envelope encryption for better performance and security. It uses AWS KMS to implement this, using a single KMS key to encrypt many private keys. Each wallet private key is protected by a unique data key, which is itself encrypted with an AWS KMS-managed key encryption key. This helps ensure that all keys remain securely encrypted at rest and in transit.

Minimal ingress and egress

The AWS account provisioned for the Secure Signer is dedicated, with no other deployments running in it to enhance security. All access to this account must occur through AWS PrivateLink and only a single client is permitted to connect to the service. Modifying this setup requires changes to multiple access control layers. Similarly, the enclave is accessible only from within the Amazon Elastic Compute Cloud (Amazon EC2) instance through a vsock port.

Scaling improvements to AWS Nitro Enclaves C SDK

The Coinbase team implemented several targeted enhancements to the Nitro Enclaves C SDK, boosting the throughput of KMS operations through the enclave more than tenfold. These improvements included improving concurrency around wake-up signals, resource deallocation, improving connection efficiency with the AWS KMS client, and improvements in vsock proxy throughput for concurrent workers. Efforts to further mitigate performance bottlenecks are ongoing, by partnering with the AWS team. With existing improvements, wallet creation and signing latency are typically below 200ms within the Secure Signer running inside the enclave.

Conclusion

Coinbase’s secure and scalable key management solution for developer wallets using AWS Nitro Enclaves provides strong isolation, verifiable execution, and a minimal attack surface. This is essential for protecting funds while supporting programmatic wallet access. By running the Secure Signer process in a trusted, verifiable compute layer, Coinbase enabled a secure channel between the developer and the wallet infrastructure, providing developers with full control over their funds. This approach provides web3 developers with the secure, programmatic wallet access they require. Coinbase continues to partner with AWS on performance and tooling for Nitro Enclaves to improve wallets even further and empower their developer customers.

About the authors