At Kaleido, your security is key. That’s why we’ve integrated multiple measures to ensure your keys stay safe and secure.
In a Kaleido blockchain network, there are a number of sensitive key materials involved to make everything work. Let’s review what they are and the techniques Kaleido employs to keep them safe from hackers.
A Geth node uses two separate keys. The node key is a private key that signs all messages exchanged with other nodes in the blockchain network. Every node when receiving a message will verify the signature against the enode ID which encapsulates the public key. In addition, if the Geth node is designated as a block signer, it is responsible for sealing the blocks by signing the standard set of block header fields. The signing key is separate from the node key and must be saved in the node’s wallet as a user account. Finally, Kaleido by default provides a user account in all Geth nodes that allows users to designate as transaction signing keys. In other words, Kaleido provides a built-in wallet that resides on Geth nodes for client applications to use. Note that Kaleido generates a single user account in the wallet which is used for both signing blocks, and is available for client applications to use to sign transactions.
A Quorum node uses three keys in the functionality of the blockchain. Similar to Geth nodes, it also requires a node key for signing messages exchanged with other nodes in the blockchain network. It also uses the same key to sign blocks when the node is a Raft leader (when the network uses the Raft consensus[1]) or an IBFT validator (when the network uses IBFT consensus). Also similar to Geth nodes, Kaleido provides a built-in wallet in Quorum nodes and generates a user account in the wallet which is available for client applications to use to sign transactions. Finally, Quorum’s Constellation component, responsible for processing private transactions and managing private states, has its own key pair which Constellation uses to encrypt and decrypt private transaction payloads.
The sensitive nature of these private keys means that extreme care must be taken to keep them safe. The first measure Kaleido employs when handling key materials is that they get generated and destroyed along with the node and never leave the node’s file system. Kaleido never saves copies of private keys in its configuration databases. When a new node gets added to a blockchain network, 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 attacks by sniffing the network packages.
On top of that, Kaleido also supports encrypting the key materials with a master encryption key managed by a key vault service. On a per node basis, Kaleido users can choose to further protect their key materials with Amazon Key Management Service (KMS). With KMS enabled, the key materials on the file system will be encrypted by the master key in the user’s KMS service, and only decrypted with that same master key when the node starts up. This further secures the attack surface involving the mounted file system. If the user has reasons to suspect that the target node’s file system may be under attack, he or she can easily block the attack by revoking the access to the master encryption key such that all subsequent decryption requests are rejected. This way the hackers will not be able to obtain the keys in clear text. Last but not least, Amazon KMS service provides audit logs that can help trace decryption requests and track down illegitimate activities.
In the following sections we will demonstrate using KMS to protect Geth node key materials in Kaleido. The same procedure is applicable to Quorum nodes.
First we need to create a master encryption key in our own AWS account and designate a user to be able to access it and perform encryption and decryption actions.
After logging into AWS console, select IAM and go to the IAM console. On the left select the “Groups” navigation link, then click the “Create New Group” button to create a new user group. After typing in a group name, such as “KMS-Users”, click “Next Step” to show the “Attach Policy” panel. AWS defines a large number of policies for access control purposes. Use the filter input field and type in “KeyManagement”. There should be exactly one policy called “AWSKeyManagementServicePowerUser” to be displayed in the filtering result. Select it and create the group.
Next let’s create a new user that will act as the delegate for client applications to access the master key. In the IAM console, click “Users” link in the navigation panel. Click “Create New User”. Type in a name, such as “KMS-User1”, and select “Programmatic Access” in the Access Type section. Click “Next: Permissions” to display the permissions panel. Select the “Add user to group” button on the top and select the group that was created above. Review the details and create the user.
After the user is successfully created, select it again to display the details panel. Select the “Security credentials” tab and create a pair of access credentials by clicking the “Create access key” button. The resulting access key ID and secret access key will be used to configure Kaleido in the following steps.
Next let’s create the encryption key. Back in the IAM console, select the “Encryption keys” navigation link. Click “Create key” button to create the key. Make sure to assign the user created above to be the key’s administrator and account that can call encryption and decryption requests. For the required alias, you can give any value. Note that if you use “kaleido” as the alias, then you can omit the key ID parameter when configuring the node in Kaleido below because that’s the default value.
Now let’s proceed to use the newly created master encryption key for securing our blockchain nodes in Kaleido.
Back in Kaleido, create an environment as you do normally. Now when you add a node to the environment, notice that there is an additional option for adding integration options:
Click the “Integrations” button to expose the options panel. This panel includes a number of settings useful to customize access to the node, including using a key vault service to encrypt and decrypt sensitive key materials in the node. If you have already configured a key vault credentials before, you can simply select that from the drop down menu. If this is the first time using this feature, or if you would like to configure a new set of key vault credentials, select “Create New KMS”.
In the form that is displayed, notice that “AWS” has already been selected. In the future, support for key vault services from other cloud providers will be added. Fill in the required fields:
Click “CONTINUE” and finish adding the node.
Any nodes that are added with key vault protection will benefit from the enhanced security and ability to trace the usage via the audit log. To learn more about the AWS Key Management Service, visit the documentation page at https://aws.amazon.com/documentation/kms/.
[1] Blocks proposed by a Raft leader is currently not signed, as of release 2.0.2. But this pull request from the Kaleido team https://github.com/jpmorganchase/quorum/pull/395 adds leader’s signature to the block.
Your guide to everything from asset tokenization to zero knowledge proofs
Download Now
Learn how Swift, the world’s leading provider of secure financial messaging services, utilizes Kaleido in its CBDC Sandbox project.
Download Now
