AWS Database Blog

AWS Nitro Enclaves for secure blockchain key management: Part 1

Public blockchains are used for a variety of use cases, like decentralized finance (DeFi) apps, non-fungible token (NFT) apps, or cross-border payments. Blockchains differ in their protocol and consensus design, implementation language, and smart contract capabilities.

Determining how external participants can be incentivized to join a network running their own node is key in economic design principals rooted in game theory, where you’re designing the network to be more decentralized while improving robustness.

In this post, we address architectural challenges in blockchain operations using AWS Key Management Service (AWS KMS) and explain how AWS Nitro Enclaves offers flexible support for low-level blockchain operations such as scaling out key management in a secure fashion.

We explain why Nitro Enclaves is well suited to run blockchain key management tasks that an AWS KMS-based architecture can’t address.

In Part 2, we provide a step-by-step walkthrough of how to sign an Ethereum transaction using the proposed Nitro Enclaves-based architecture.

In Part 3, we conduct a technical deep dive into Nitro Enclaves and explain features like cryptographic attestation. We also explain the general architecture of a Nitro Enclaves-based Ethereum signing application.

Challenges with an AWS KMS-based approach

AWS KMS-based solutions, for example as described in the post How to sign Ethereum EIP-1559 transactions using AWS KMS, are a great fit for blockchains like Ethereum that use the secp256k1 elliptic curve. On the other hand, there are limitations when it comes to low-level tasks and how to manage access to private keys:

  • AWS KMS supports the secp256k1 elliptic curve but doesn’t support alternative curves like bls12-381 (Ethereum 2).
  • A multi-tenant approach for key management could conflict with compliance requirements.
  • Each KMS key (blockchain account) is charged $1 per month independent from its usage. That can lead to high fixed costs if a large amount of Blockchain accounts is required.
  • Provided blockchain clients like geth for Ethereum or opera for Fantom don’t have native support for AWS KMS and require the private keys to be available on the file system.

To address these challenges, we introduce Nitro Enclaves as a secure compute environment for low-level blockchain tasks and scale out blockchain account management without using AWS KMS as the central key management system.

Nitro Enclaves provide a fully isolated compute environment inside an Amazon Elastic Compute Cloud (Amazon EC2) instance using the same Nitro Hypervisor technology that provides CPU and memory isolation for EC2 instances.

Solution overview

The following diagram illustrates the architecture for our Nitro Enclaves-based blockchain application.

This architecture showcases the cryptographic attestation feature of Nitro Enclaves together with AWS KMS.

Nitro Enclaves provides an isolated compute environment to protect and securely process highly sensitive data such as private keys for blockchain operations. Communication between the EC2 parent instance and the enclave is limited to a secure local vsocks channel.

EC2 instances hosting Nitro Enclaves aren’t publicly accessible and are located in private subnets. EC2 instances have secure internet access via a NAT gateway to download operating system updates and other packages.

Communication with AWS services like AWS KMS or AWS Secrets Manager is kept private via interface VPC endpoints that have been placed inside the subnets in each Availability Zone.

The AWS Lambda function shown in this architecture is not required for a production-ready setup.

Also, the provided AWS Cloud Development Kit (AWS CDK) source just covers the area marked in red. For information about the Amazon Managed Blockchain Ethereum node, refer to Deploy an Ethereum node on Amazon Managed Blockchain.

The following diagram depicts the components deployed inside the EC2 instances and the general communication flow with external AWS services like Secrets Manager or AWS KMS.

Signing flow

The following steps explain on a high level how an Ethereum transaction is signed inside Nitro Enclaves. One prerequisite is that the Ethereum private key has already been encrypted and stored inside the Secrets Manager slot that was created along with AWS CDK. For additional information about the Ethereum key related configuration, refer to Part 2.

The signing flow is as follows:

  1. A signing request arrives at the http_server component.
  2. http_server downloads the encrypted Ethereum private key from Secrets Manager and passes it to the signing_server running inside the enclave, along with the signing request payload.
  3. signing_server uses the kmstool-enclave-cli provided by the AWS Nitro System to decrypt the Ethereum private key. The kmstool-enclave-cli uses the cryptographic attestation feature to gain permission to run the decrypt operation on the KMS key.
  4. All decrypt requests not originating from inside the enclave are by default rejected by AWS KMS.
  5. After signing_server gets access to the plaintext Ethereum key, it uses it to sign the Ethereum transaction. The signed transaction is returned to http_server. The plaintext private key is then deleted from inside the enclave.

For technical details, such as the secure vsocket-based communication or the cryptographic attestation feature, refer to Part 3.

Conclusion

In this post, we provided a high-level introduction to Nitro Enclaves and explained why AWS Nitro is well suited to run critical blockchain workloads. We also explained what aspects are important when it comes to designing and architecting a secure and reliable blockchain transaction processing environment.

In Part 2 of this post, we conduct a walkthrough of the configuration aspects like KMS key policies and how to sign your first Ethereum EIP-1559 transaction inside Nitro Enclaves.

Now go read Part 2 of the post and sign your first Nitro Enclaves-based Ethereum transaction!

About the Author

David Dornseifer is a Blockchain Architect with the Amazon ProServe Blockchain team. He focuses on helping customers design, deploy and scale end-to-end Blockchain solutions.