Building a Secure Crypto Wallet with Nitro Enclaves and AWS EKS

·

Introduction

In the world of Web3, a wallet serves as a fundamental software application for managing digital assets. As with any software, wallets are prime targets for cyber attackers. These applications store user private keys, and even though these keys are often encrypted at rest, they must be decrypted in memory to sign transactions. This creates a critical security vulnerability. Ensuring that wallet applications operate within the most secure environment possible is paramount.

Trusted Execution Environment (TEE) technology offers a powerful solution, enabling highly secure and trusted operations for wallet applications. AWS Nitro Enclaves provides a robust TEE solution compatible with Intel, AMD x86 processors, and Graviton ARM architecture processors. It supports EC2 instances and Amazon EKS (Kubernetes) services. This article demonstrates how to implement a crypto wallet application leveraging Nitro Enclaves TEE technology, deployed on the AWS EKS container platform.

Solution Overview

This solution builds a sample encrypted wallet application deployed on Amazon EKS using Nitro Enclaves. It implements key functionalities such as wallet account generation and transaction signing.

The deployment architecture incorporates several AWS services, including Nitro Enclaves, Amazon EKS, AWS KMS, and DynamoDB. Nitro Enclaves provides an isolated compute environment (Enclave) on EKS worker nodes, safeguarding sensitive data like blockchain private keys. Communication between the Enclave, EKS Pods, and external AWS services (e.g., AWS KMS, Secrets Manager) is restricted to secure local vsock channels.

Generating an Account

The generateAccount API is called to create a wallet account within the Enclave. Envelope encryption is performed using AWS KMS, and the encrypted private key is stored in DynamoDB. The communication workflow for this process is as follows:

  1. The parent instance client receives the generateAccount API call.
  2. The getIAMToken() function is called to retrieve IAM Role credentials.
  3. Credentials and the generateAccount API request are sent via vsock.
  4. The encrypted wallet account is generated inside the Nitro Enclave.
  5. Using the credentials and attestation, a KMS generateDataKey API call is requested.
  6. The generated data key is used to encrypt the account information.
  7. The encrypted account information is sent back to the parent instance via vsock.
  8. An API call saves the encrypted account information to DynamoDB.

Signing a Transaction with a Private Key

The wallet private key is decrypted within the Enclave and used to sign the transaction. The communication flow is detailed below:

  1. The parent instance client receives the sign API call.
  2. The getIAMToken() function is called to retrieve IAM Role credentials.
  3. Credentials and the sign API request are sent via vsock.
  4. The KMS API is used to decrypt the encrypted data key.
  5. The decrypted data key is used to decrypt the wallet's encrypted private key.
  6. The decrypted wallet private key signs the message.
  7. The signature is returned to the parent instance via vsock.

Envelope Encryption

Amazon KMS supports envelope encryption to protect data. This technique involves using a data key generated by KMS to encrypt the wallet's private key. The discussed solution employs an AES scheme for data encryption.

Application Deployment

Preparation

Before deployment, ensure you have an EKS cluster with the necessary environment pre-configured. Required tools and software include the AWS CLI, eksctl, Docker, kubectl, Golang, and jq. Configure your AWS credentials appropriately.

Cluster Configuration

The demonstration uses the following key cluster configuration:

IAM Configuration

Create an IAM Role (EC2 service role), e.g., EKSNodeRoleForNitroEnclaveApplication, and attach it to each worker node in the cluster. This role must have permissions for DynamoDB actions (CreateTable, PutItem, DescribeTable, GetItem) and KMS actions (Decrypt, GenerateDataKey). Replace the KMS ARN in the policy resource with the one you create.

KMS Configuration

Create a customer-managed symmetric key in KMS for data encryption and decryption. Steps include selecting a symmetric key, adding an alias, choosing key administrators, defining key usage permissions for the IAM role created earlier, and noting the key's ARN for the IAM policy.

Deploying the Wallet Application

This section outlines the manual deployment process for the demonstration code. Adjust the REGION parameter in the Dockerfile and code as needed for your environment.

  1. Compile the Nitro Enclave Image File: Clone the example repository, build the source code, and use the Nitro CLI to build the Enclave Image File (.eif).
  2. Deploy the Docker Image to ECR: Build the local Docker image for the EKS runtime, log in to Amazon ECR, create a repository, tag your local image, and push it to ECR.
  3. Create the Deployment YAML File: Write a kms_server_deployment.yaml file, ensuring the image value points to your ECR URI.
  4. Deploy the Application: Apply the deployment YAML using kubectl apply and monitor the pod status until it shows as Running.
  5. Compile and Deploy the Client Application: Repeat the image build and ECR push process for the client application, create its deployment YAML file (appclient-deployment.yaml), and deploy it.

👉 Explore secure deployment strategies

Environment Cleanup

To avoid ongoing costs after deployment and testing, clean up the deployed components by deleting the pods and deployments using kubectl delete.

Function Demonstration

Wallet Generation

The wallet generation logic executes within the Enclave, with results stored in DynamoDB. After deploying the parentk8s pod, the code runs automatically, storing wallet data in the AccountTable, which includes fields like KeyId, Name, EncryptedPrivateKey, Address, and EncryptedDataKey. You can view this data in the DynamoDB console.

Transaction Signing

Transaction signing also occurs within the Enclave. The demonstration stores relevant data in the SignedValueTable in DynamoDB, which contains Name, Transaction, and SignedValue fields.

Technical Deep Dive

This solution implements basic wallet functionality using Nitro Enclaves. The process is broken down to clarify the underlying technical principles.

Wallet Generation Process

  1. An API backend service running on EKS receives a wallet generation request from a client and requests temporary security credentials (IAM role) from STS for Enclave access.
  2. The backend service sends these credentials via vsock and makes a service request to the wallet application running inside the Enclave.
  3. The wallet application generates a plaintext wallet account within the secure Enclave environment.
  4. The application calls the kms:GenerateDataKey API command. The Nitro system provides a signed attestation document containing the Enclave's unique measurements (PCRs) to prove its identity and establish trust with KMS.
  5. The Enclave application sends the attestation document via vsock to EKS. A KMS proxy running on the pod forwards it to AWS KMS.
  6. KMS verifies the document was signed by the Nitro Hypervisor and that the PCRs defined in the KMS key policy match those in the document. It then executes GenerateDataKey, encrypts the data key using the Enclave's public key (from the attestation document), and sends it back via vsock.
  7. The Enclave uses its private key to decrypt the encrypted data key and then uses this data key to encrypt the account information.
  8. The encrypted account information is sent via vsock to the backend program running on EKS.
  9. The backend program calls an API to save the encrypted account information to DynamoDB.

Transaction Signing Process

  1. The API backend service on EKS receives a signing API request and requests temporary security credentials (IAM role) from STS for DynamoDB access.
  2. The service calls an API to retrieve the required encrypted account information (EncryptedPrivateKey and EncryptedDataKey) from DynamoDB based on the request.
  3. The transaction information, encrypted account info, and encrypted data key are sent via vsock to the Enclave.
  4. The application inside the Enclave calls the kms:Decrypt API command. The Nitro system again provides a signed attestation document.
  5. The application sends the attestation document and the encrypted data key via vsock to EKS, which are forwarded to AWS KMS via the KMS proxy.
  6. KMS validates the attestation document. Upon successful validation, it performs the Decrypt operation and re-encrypts the data key using the Enclave's public key before sending it back via vsock.
  7. The Enclave uses its private key to decrypt the re-encrypted data key, obtaining the plaintext data key, which is then used to decrypt the wallet's private key.
  8. The Enclave application uses the decrypted private key to sign the transaction.
  9. Finally, the signature is sent back via vsock to the backend program running in the EKS container.

Kmstool-Enclave-CLI

The kmstool-enclave-cli is a command-line tool provided by AWS that abstracts the Nitro Enclave attestation logic. It offers two main commands:

Frequently Asked Questions

What is a Trusted Execution Environment (TEE)?
A TEE is a secure area within a main processor. It ensures that code and data loaded inside are protected with respect to confidentiality and integrity. Operations inside the TEE are isolated from the main operating system, providing a higher level of security.

Why use AWS Nitro Enclaves for a crypto wallet?
Nitro Enclaves provide an isolated, highly secure environment for processing sensitive data like private keys. They help protect against various attack vectors, including those from a compromised host OS, by ensuring the private key material is never exposed in plaintext outside the Enclave.

What is envelope encryption?
Envelope encryption is the practice of encrypting data with a data key, and then encrypting that data key with a master key stored in a secure service like AWS KMS. This approach combines the performance benefits of symmetric encryption with the security benefits of a managed key service.

How does attestation work with Nitro Enclaves and KMS?
Attestation provides proof of the Enclave's identity and integrity. The Nitro Hypervisor generates a cryptographically signed document containing measurements (PCRs) of the Enclave. AWS KMS can verify this document before performing operations like decryption, ensuring it only releases keys to a known and trusted Enclave.

Can this solution be used for other sensitive data besides crypto wallets?
Absolutely. While demonstrated for crypto wallets, Nitro Enclaves are suitable for any application processing highly sensitive data, such as personally identifiable information (PII), financial data, healthcare records, or proprietary algorithms, within an isolated environment.

What are the cost considerations for this architecture?
Costs are associated with the underlying EKS cluster (worker nodes), Nitro Enclave resources (vCPU/memory), AWS KMS API calls, DynamoDB storage and read/write operations, and data transfer. The solution should be sized appropriately for production workloads.

Conclusion

This article introduced and demonstrated a wallet application implemented using AWS Nitro Enclaves. By creating and using private keys within an isolated, secure environment, the solution ensures keys are protected from hackers and theft. Beyond wallets in the Web3 space, Nitro Enclaves technology can secure crypto assets in any scenario involving digital asset management.

Furthermore, Nitro Enclaves are applicable for general sensitive data processing. Running applications in an isolated security perimeter is crucial for handling personal identity information, credit card numbers, asset details, and other PII. This capability is also vital for operating nodes on permissionless, decentralized networks where security and trust are paramount.