Securing Tendermint apps with Fortanix DSM & TMKMS

Tendermint achieves something called Byzantine fault tolerance, which in simple words means that it solves the ‘Byzantine Generals Problem’, best explained in game theory. In this, the ancient city of Byzantium is under siege from multiple generals, the generals need to coordinate and attack at once; failing to do so and attacking in a disorganized way leads to a defeat, to add to the problem the generals do not possess a secure way to communicate amongst themselves.

Centralized systems do not face this problem as they choose to trust a central authority, which is the exact opposite of the decentralized systems, thereby making the problem of Byzantine generals the problem of modern-day blockchains.

For those who are new to the blockchain world, the idea of consensus is fundamental to the decentralized belief, it is what establishes the trust and harmony between the unknown peers in the network.

One of the most known protocols for consensus is Proof of Work (PoW), to give an example Ethereum network uses the PoW protocol to agree on the state recorded on the network. The answer to how PoW solves the above problem is in its name, ‘work’ which is also called ‘mining’.

The idea with PoW is that the longest chain is the valid one, as to achieve this longer chain than others, more computational work must be put in. That implies that a miner who has malicious intent of creating some trouble must consistently ‘mine’ faster than others.

Despite all these advantages, it is quickly becoming a less popular protocol for blockchain networks, as solving these puzzles (mining) is becoming very expensive computationally (add to that the global semiconductor shortage), so much so that now mining pools are becoming centralized pools in a decentralized network.

And while we are on the example of Ethereum, the latest change for the Ethereum network points us to a better protocol than PoW i.e., Proof of Stake (PoS). Proof of Stake validators does function like the miners in PoW, with an added caveat of stake.

For example, Validators create and commit new blocks or transactions to the network and in return for adding new blocks, they get rewarded from the network. This makes the protocol more energy efficient as there is no race to solve computationally expensive puzzles to get rewarded.

On the contrary, a validator that attests malicious blocks gets penalized and as they have a stake in the network, it manifests as loss of stake for the validator. Another added complexity with Ethereum now is the addition of shard chains, which have an end goal of increasing.

Cosmos Hub is one such network that is built on the Proof-Of-Stake (PoS) protocol using Tendermint. It consists of thousands of interconnected blockchains. PoS chains reward well-acting validators and penalize faulty ones.

Hence, it’s in the self-interest of these validators to keep the validator nodes secure from attacks that undermine the network and harm the validator’s stake. Also, part of the stake is delegated by other parties to a validator making them a target for attacks.

Protecting its key is the most important security consideration for a validator in the system design. Tendermint uses ed25519 signatures for this consensus. Upon the creation of a validator node, the consensus key is created in the default JSON file format called ‘priv_validator_key. json’. These nodes are responsible for committing new blocks in the blockchain by participating in the consensus protocol by using their keys for signatures.

It’s not uncommon for these networks to recommend a Key Management System (KMS) for storing such consensus keys, like the Tendermint KMS (TMKMS) which provides remote signing features that enable signing from a KMS.

Tendermint enables us to separate the key from the nodes. Traditionally TMKMS has been integrated with HSM for key management like YubiHSM2 and Ledger. But with the integration of Fortanix Data Security Manager (DSM) with TMKMS, you can enable your tendermint node to use DSM for the key management and signing for consensus.

Fortanix DSM runs on intel SGX, which means the keys are secured inside Intel SGX secure enclaves and decrypted only when being processed by the CPU in the enclaves. Fortanix DSM provides you with a centralized UI that can be used to manage all your KMS needs.

It also provides HSM-grade security and tamper-proof audit logs. You also get full key lifecycle management that involves generation, expiration, deactivation, destroying, etc from a single interface. With the enhancement of DSM support in TMKMS, you can now create and manage the consensus keys for your validators from a single DSM interface.

You can even offload the signing process to Fortanix DSM by using the “Remote signer” in Tendermint. This lets Fortanix DSM handle the signing operations on behalf of the Tendermint node.

The key creation and signing of votes/proposals are done by Fortanix DSM thereby reducing the attack surface, as a compromised validator node doesn’t expose the private keys when using DSM. And with runtime encryption provided by Fortanix Enclave OS, which is used by Fortanix DSM, it’s not possible to get the stored keys on Fortanix DSM even during runtime, thereby providing an end-to-end solution for securely setting up a Validator on the blockchain.

To use TMKMS with DSM, build the former from the official Github repo by issuing “cargo build --features fortanixdsm”. You can then very easily create a key on DSM, it must be an EC key with curve Ed25519 (consensus key). To do so, create a security object in DSM like shown in Figure 1, we’ve called it Consensus key in our DSM account.

Once you have the key created and TMKMS built, you can modify the toml configuration for the KMS by following the steps given on the github repo. The following should give us the idea of how that would like,

	### Fortanix DSM Signer Configuration
	[[providers.fortanixdsm]]
	pinpoint = "https://sdkms.fortanix.com"
	api_key = <API_KEY FOR DSM>
		signing_keys = [
	        { 
                chain_ids = ["testhub"], 
                type = "account", 
                key_id ="<KEY_ID FOR DSM KEY" 
            }, 
			{ 
				chain_ids=["testhub"],
				type="consensus" , 
				key_name="Consensus Key" 
			}, 
		]

You can either provide the key id for the security object that you can get from the DSM or use the name of the key. And to authenticate with Fortanix DSM you can use the API Key provided by DSM.

After you have started the TMKMS with this configuration toml file, you can see the signing operation in the CLI of TMKMS, displayed below in Figure 2.

Fortanix DSM also provides tamper-proof audit logs that help you monitor the usage of your keys; Figure 3 shows the logs for our security object.

Conclusion:

As more and more blockchain networks move to PoS protocol leveraging the Tendermint core for their consensus engine, the need to securely handle the keys for these validators will become greatly important. Tendermint KMS is one such solution that addresses these problems. Fortanix DSM is an enterprise-grade product that with added support for Tendermint KMS, allows users to benefit from the leading extended KMS feature set of Fortanix DSM and the benefits of Confidential computing provided by Fortanix Enclave OS.