This project represents an example implementation of an AWS Nitro Enclave based blockchain account management solution a.k.a. a wallet. It's implemented in AWS Cloud Development Kit (CDK) v2 and Python.
This repository contains all code artifacts for the following three blog posts:
- AWS Nitro Enclaves for secure blockchain key management: Part 1
- AWS Nitro Enclaves for secure blockchain key management: Part 2
- AWS Nitro Enclaves for secure blockchain key management: Part 3
For an overview of how to design an AWS Nitro Enclave based blockchain application please have a look at the first blog post.
For a walkthrough of how to deploy and configure the Nitro Enclave based blockchain key management solution please refer to the second blog post.
For a deep dive into Nitro Enclaves and the explanation of features like cryptographic attestation and additional information about the general architecture of a Nitro Enclaves-based Ethereum signing application please refer to third blog post.
For an AWS Workshop Studio based walkthrough please refer to Leveraging AWS Nitro Enclaves for Secure Blockchain Key Management.
For Nitro Enclave advanced networking patterns, please refer to the respective application folders.
Deploying the solution with the AWS CDK The AWS CDK is an open-source framework for defining and provisioning cloud application resources. It uses common programming languages such as JavaScript, C#, and Python. The AWS CDK command line interface (CLI) allows you to interact with CDK applications. It provides features like synthesizing AWS CloudFormation templates, confirming the security changes, and deploying applications.
This section shows how to prepare the environment for running CDK and the sample code. For this walkthrough, you must have the following prerequisites:
- An AWS account.
- An IAM user with administrator access
- Configured AWS credentials
- Installed Node.js, Python 3, and pip. To install the example application:
When working with Python, it’s good practice to use venv to
create project-specific virtual environments. The use of venv
also reflects AWS CDK standard behavior. You can find
out more in the
workshop Activating the virtualenv.
-
Install the CDK and test the CDK CLI:
npm install -g aws-cdk && cdk --version
-
Download the code from the GitHub repo and switch in the new directory:
git clone https://github.com/aws-samples/aws-nitro-enclave-blockchain-wallet.git && cd aws-nitro-enclave-blockchain-wallet
-
Install the dependencies using the Python package manager:
pip install -r requirements.txt
-
Specify the AWS region and account for your deployment:
export CDK_DEPLOY_REGION=us-east-1 export CDK_DEPLOY_ACCOUNT=$(aws sts get-caller-identity | jq -r '.Account') export CDK_APPLICATION_TYPE=eth1 export CDK_PREFIX=dev
You can set the
CDK_PREFIX
variable as per your preference. -
Trigger the
kmstool_enclave_cli
build:./scripts/build_kmstool_enclave_cli.sh
-
Deploy the example code with the CDK CLI:
cdk deploy ${CDK_PREFIX}NitroWalletEth
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable decrypt from enclave",
"Effect": "Allow",
"Principal": {
"AWS": <devNitroWalletEth.EC2InstanceRoleARN>
},
"Action": "kms:Decrypt",
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"kms:RecipientAttestation:ImageSha384": <PCR0_VALUE_FROM_EIF_BUILD>
}
}
},
{
"Sid": "Enable encrypt from lambda",
"Effect": "Allow",
"Principal": {
"AWS": <devNitroWalletEth.LambdaExecutionRoleARN>
},
"Action": "kms:Encrypt",
"Resource": "*"
},
{
"Effect": "Allow",
"Principal": {
"AWS": <KMS_ADMINISTRATOR_ROLE_ARN>
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion",
"kms:GenerateDataKey",
"kms:TagResource",
"kms:UntagResource"
],
"Resource": "*"
}
]
}
To leverage the provided generate_key_policy.sh
script, a CDK output file needs to be provided.
This file can be created by running the following command:
cdk deploy devNitroWalletEth -O output.json
After the output.json
file has been created, the following command can be used to create the KMS key policy:
./scripts/generate_key_policy.sh ./output.json
If the debug mode has been turned on by appending --debug-mode
to the enclaves start sequence, the enclaves PCR0 value in the AWS KMS key policy needs to be updated to 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
,
otherwise AWS KMS will return error code 400
.
Use the command below to create a temporary Ethereum private key.
openssl ecparam -name secp256k1 -genkey -noout | openssl ec -text -noout > key
cat key | grep priv -A 3 | tail -n +2 | tr -d '\n[:space:]:' | sed 's/^00//'
Use the following command to calculate the corresponding public address for your temporary Ethereum key created in the previous step. keccak-256sum binary needs to be made available to execute the calculation step successfully.
cat key | grep pub -A 5 | tail -n +2 | tr -d '\n[:space:]:' | sed 's/^04//' > pub
echo "0x$(cat pub | keccak-256sum -x -l | tr -d ' -' | tail -c 41)"
Please be aware that the calculated public address does not comply with the valid mixed-case checksum encoding standard for Ethereum addresses specified in EIP-55.
Replace the Ethereum key placeholder in the JSON request below and use the request to encrypt and store the Ethereum key
via the Lambda test
console:
{
"operation": "set_key",
"eth_key": <ethereum_key_placeholder>
}
Use the request below to sign an Ethereum EIP-1559 transaction with the saved Ethereum key using the Labda test
console:
{
"operation": "sign_transaction",
"transaction_payload": {
"value": 0.01,
"to": "0xa5D3241A1591061F2a4bB69CA0215F66520E67cf",
"nonce": 0,
"type": 2,
"chainId": 4,
"gas": 100000,
"maxFeePerGas": 100000000000,
"maxPriorityFeePerGas": 3000000000
}
}
Once you have completed the deployment and tested the application, clean up the environment to avoid incurring extra cost. This command removes all resources in this stack provisioned by the CDK:
cdk destroy
Docker Image Push/Pull Error
- On
building
instance duringcdk deploy
step:
devNitroWalletEth: fail: docker push 012345678910.dkr.ecr.us-east-1.amazonaws.com/cdk-hnb659fds-container-assets-012345678910-us-east-1:ab3fe... exited with error code 1: failed commit on ref "manifest-sha256:7141...": unexpected status from PUT request to https://012345678910.dkr.ecr.us-east-1.amazonaws.com/v2/cdk-hnb659fds-container-assets-012345678910-us-east-1/manifests/ab3fe...: 400 Bad Request
Failed to publish asset ab3fe...:012345678910-us-east-1
- On EC2 instance pulling docker container
ab3fe...: Pulling from cdk-hnb659fds-container-assets-012345678910-us-east-1
unsupported media type application/vnd.in-toto+json
Solution
- Issue might be related building and publishing docker containers from an
arm
based instances such as Apple Silicon, requiring dockerbuildx
issue - Cleanup images from local docker repository (
docker rmi ...
) and from Amazon Elastic Container Registry (ECR) e.g. via AWS console - Set environment variable in terminal session (
export BUILDX_NO_DEFAULT_ATTESTATIONS=1
) or specify it during cdk deployment (BUILDX_NO_DEFAULT_ATTESTATIONS=1 cdk deploy
)
See CONTRIBUTING for more information.
This library is licensed under the MIT-0 License. See the LICENSE file.