This Guidance demonstrates how you can use AWS Nitro Enclaves and AWS Secrets Manager for secure blockchain transaction signing. The flexibility of AWS Nitro Enclaves allows you to create enclaves for various types of blockchain operations. The additional isolation and security inherent in the enclaves help to reduce attack surface area for your applications.
Architecture Diagram
Step 1
Deployment is based on AWS Cloud Development Kit (AWS CDK). Required Docker containers are stored on Amazon Elastic Container Registry (Amazon ECR).
Step 2
Secure access to AWS Nitro Enclave parent instances is realized through AWS Systems Manager without using secure shell (SSH).
Step 3
Customer can interact with system through AWS Lambda console or add an individual point of integration.
Step 4
Private key must be encrypted through a symmetrical key in AWS Key Management Service (AWS KMS).
Step 5
Encrypted private key is stored in AWS Secrets Manager.
Step 6
Customer triggers transaction signing request through Lambda console.
Step 7
Encrypted private key is downloaded and passed to Amazon Elastic Compute Cloud (Amazon EC2) instance along with transaction parameters.
Step 8
Request is routed through Network Load Balancers (NLB) to the next healthy Amazon EC2 instance running isolated in a private subnet.
Step 9
Amazon EC2 instance is the parent instance for the signing process running inside an AWS Nitro Enclave.
Step 10
Request (from step 5) is passed into AWS Nitro Enclave. Cryptographic attestation is used to securely communicate with AWS KMS from inside the enclave through AWS PrivateLink to get the key decrypted.
Step 11
Transaction is signed inside AWS Nitro Enclave. Signed transaction is returned to user, private key is deleted from inside the enclave.
Step 12
The transaction can now be released to the public Ethereum network through Amazon Managed Blockchain.
Step 1
Deployment is based on AWS Cloud Development Kit (AWS CDK). Required Docker containers are stored on Amazon Elastic Container Registry (Amazon ECR).
Step 2
Secure access to AWS Nitro Enclave parent instances is realized through AWS Systems Manager without using secure shell (SSH).
Step 3
Customer can interact with system through AWS Lambda console or add an individual point of integration.
Step 4
Private key must be encrypted through a symmetrical key in AWS Key Management Service (AWS KMS).
Step 5
Encrypted private key is stored in AWS Secrets Manager.
Step 6
Customer triggers transaction signing request through Lambda console.
Step 7
Encrypted private key is downloaded and passed to Amazon Elastic Compute Cloud (Amazon EC2) instance along with transaction parameters.
Step 8
Request is routed through Network Load Balancers (NLB) to the next healthy Amazon EC2 instance running isolated in a private subnet.
Step 9
Amazon EC2 instance is the parent instance for the signing process running inside an AWS Nitro Enclave.
Step 10
Request (from step 5) is passed into AWS Nitro Enclave. Cryptographic attestation is used to securely communicate with AWS KMS from inside the enclave through AWS PrivateLink to get the key decrypted.
Step 11
Transaction is signed inside AWS Nitro Enclave. Signed transaction is returned to user, private key is deleted from inside the enclave.
Step 12
The transaction can now be released to the public Ethereum network through Amazon Managed Blockchain.
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
This Guidance provides a basic blueprint to help you implement AWS Nitro Enclave for blockchain key management. Design this into your workloads with AWS CDK, so you can customize and build the procedures needed to support your business objectives.
-
SecurityRead the Security whitepaper
For secure authentication and authorization, access is granted only to instances running in the same VPC as the AWS Nitro Enclaves. This is ensured by security groups that act as a virtual firewall for your Amazon EC2 instances to control incoming and outgoing traffic.
Separate VPCs are created within two private subnets. Amazon EC2 instances running inside the subnets can only access the internet through the Network Address Translation (NAT) gateways. No inbound access to Amazon EC2 instances is possible. Administrator access to the Amazon EC2 instances is established through Systems Manager. All traffic to AWS services, like AWS KMS, is routed through the interface VPC endpoints.
Data, particularly sensitive private key material, is encrypted using AWS KMS. The ciphertext is stored in Secrets Manager. Cryptographic attestation is used to ensure that the ciphertext is decrypted from inside the AWS Nitro Enclave.
-
ReliabilityRead the Reliability whitepaper
By default, an auto scaling group deploys over two different subnets in different Availability Zones. One Amazon EC2 instance deploys in each subnet. A network load balancer (NLB) distributes the requests between both Amazon EC2 instances. The auto scaling group ensures that there are two active instances available at any time.
The enclaves run stateless and all services are loosely coupled. Changes to the resources and configs can be applied and deployed through AWS CDK to minimize human error and help your environment adapt to changes.
-
Performance EfficiencyRead the Performance Efficiency whitepaper
The services in this Guidance provide a secure, flexible, and cost-effective alternative to the purpose-built blockchain key management solutions available on AWS right now. It is a blueprint of what an AWS Nitro Enclave blockchain key management solution could look like. You can adapt the critical parts (such as key management and signing) for your specific use.
-
Cost OptimizationRead the Cost Optimization whitepaper
This Guidance avoids services and storage options with high monthly fix costs. For long-term operation, the Amazon EC2 instances can be part of an EC2 Instance Savings Plan. By default, the Guidance uses on-demand instances with the Amazon EC2 instance type as M5a.xlarge, the smallest instance currently supporting AWS Nitro Enclaves.
By leveraging a Network Load Balancer that distributes the load between two different Amazon EC2 instances running in separate availability zones (AZs), this Guidance scales to continually meet demand. It ensures this scaling and high availability through the additional Amazon EC2 instances. Because the processes inside the AWS Nitro Enclaves are stateless, new Amazon EC2 instances can be added and removed according to the demand.
-
SustainabilityRead the Sustainability whitepaper
The auto scaling group in this Guidance ensures a minimum number of instances are running, and new instances are both launched and terminated based on changes to demand.
Implementation Resources
A detailed guide is provided to experiment and use within your AWS account. Each stage of building the Guidance, including deployment, usage, and cleanup, is examined to prepare it for deployment.
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Related Content
AWS Nitro Enclaves for secure blockchain key management: Part 1
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.