Nodes are the network resources responsible for transaction execution, block signing/consensus and maintaining the ledger. They are the critical piece to the entire blockchain apparatus, and as such, their key materials are of paramount importance to the security and integrity of the network. Kaleido employs multiple measures to protect these keys.
Firstly, key materials are always generated and destroyed along with the node and never leave the node’s file system. No copies are ever saved in the backend configuration databases, ensuring isolation from the various microservices and platform layers. When a new node gets added to an environment, Kaleido generates the keys and saves them to the node’s configuration files that are only accessible by the containers inside the Kubernetes pod for the node. The keys stay there until the node gets deleted, at which point the mounted directories containing the configurations files get cleaned up. As a result, private keys are always “at rest” and never “in-transit”. This eliminates a significant attack surface and keeps the keys safe from malicious hackers that attack by sniffing the network packages.
As an additional security measure, Kaleido offers the option to encrypt the mounted key materials with a master encryption key managed by a key vault service. On a per node basis, users can elect for further protection by implementing Amazon’s Key Management Service (KMS). With KMS enabled, the key materials on the node’s file system will be encrypted by the master key in the user’s KMS, and only ever decrypted with that same master key when the node starts up. This further secures the attack surface involving the mounted file system and allows the user to revoke access to the master key if there is reason to believe the node is under attack. KMS also provides a transparent audit trail for all decryption requests, allowing any illegitimate or abnormal requests to be quickly identified.
KMS-enablement must be configured prior to creating the node. Refer to the Creating a Node with AWS Integrations section for instructions on enabling KMS via the user interface. Refer to the Understanding the Kaleido API documentation for instructions on enabling KMS via the Kaleido API. Note that if you elect to use the raw API, you must first create a
kms configuration object which is passed as a required parameter on the node creation call. The instructions for generating an admin user with access to a master encryption key are outlined below in the Configuring an Encryption Key section. The AWS user and encryption key must be properly provisioned in order to successfully create a KMS configuration.
Configuring an Encryption Key
The KMS blog post provides a comprehensive walkthrough on generating a master encryption key using the AWS Identity Access Management (IAM) service and configuring the node to leverage this key for decryption purposes. Below is a high-level recap of the various steps:
- Log into the AWS console and navigate to the IAM Service.
- Click the Groups tab in the IAM navigation panel and proceed to Create a New Group.
- Apply the
AWSKeyManagementServicePowerUserpolicy to the group and finish the creation.
- Click the Users tab in the IAM navigation panel and proceed to Create a New User.
Programmatic Accessto the user’s Access Type and click the Permissions button to apply permissions for the user.
- Select the Add User to Group option at the top and add the user to the newly created group.
- Review the the settings for the user and click Create User to finish.
- You will be redirected to a page displaying the user’s key pair – Access key ID and Secret access key.
- Click Show next to the hidden value for Secret access key to display the secret. Record the secret and store it safely. This is the only time it can be displayed. Click the Close button to exit this screen.
- Next, click the Encryption Keys tab in the IAM navigation panel to create a master encryption key for your node
- Click Create Key at the top of the screen and assign your previously created user as the key’s administrator. This allows incoming calls that supply the Access key ID and Secret access key to ultimately access the master key for decryption purposes.