TMKMS

HSM for Signing

To ensure high security of your validator, you will want to sign your votes and block proposals using a HSM. ( Hardware security module )

Why use a HSM

Tendermint introduction

In the Tendermint consensus, all validators in the active validator set participate by submitting block proposals and voting on them (using prevotes and precommits).

The vote of your validator is authenticated using a cryptographic signature, so that other people know that the vote came from you and no one can impersonate you (which would break the consensus mechanism).

This coordinated consensus, which is split into several steps, ensures that at least 2/3+ of the validators have the same view of the network ( state of the blockchain, transactions and application ) since it requires 2/3+ votes for a block in order to finalize it.

With this restriction in place, we would assume that it is impossible for two different chains (forks) to exist a time, since it is not possible to get 2 times 2/3+ votes on two conflicting blocks ( containing different transactions, e.g. double-spending ) in a 3/3 validator set.

Double signing

However, this excludes the scenario of double voting/proposing.

In this scenario, the byzantine proposer in the consensus round creates two conflicting blocks and sends them out to the network.

If we assume that we also have other byzantine actors in the validator set which want to profit from both chains, these will also vote for both blocks.

That means that honest nodes in the network could see 2 different blocks at the same height with different contents and hashes. From this point on the network has forked.

Outside viewers of the network will not know which block is correct and from now on there will not be a single truth. This is the exact scenario we want to prevent with PBFT-like consensus systems.

How Cosmos prevents forks

Now that we know the reason that causes forks:

• Conflicting votes by the same validator

It can be summarized as double signing. In order to create two conflicting votes, a validator needs to sign two consensus messages for the same HRS ( pair of (block-) height, (consensus-) round, (consensus-) step ) pair with its key.

Tendermint allows other validators to record evidence of byzantine behaviour in blocks. Cosmos makes use of this features and slashes validators that double sign.

This strict slashing condition makes it extremely important for validators to avoid double signing in order to ensure network security and prevent being slashed.

Problems of the default signing implementation

Lets assume a scenrio in which your validator host is compromised by a malicious actor who wants to financially hurt you and your customers (people staking tokens with you).

If you are using the priv_validator_key.json, which stores the private key associated with your validator on the file system, the attacker can compromise your host and steal your priv_validator.json file. From then on, he has the ability to sign any consensus message with your validator’s key.

That way, the attacker could double sign on your behalf, triggering the slashing conditions for you forever since validator keys cannot currently be replaced, ruining your validator.

For this reason, it’s crucial that your validator key cannot be stolen, even if your node is compromised.

The solution

A HSM is a separate hardware component that stores keys and - unless configured to perform differently - will not allow you to extract the private keys it stores. However, it will use the private key to sign/encrypt data for you.

HSMs use special tamper-proof secure elements which make it extremely hard to extract the secret keys, even with physical access.

This allows you to store your validator private key on a HSM and not leave it exposed on the filesystem of the validator host.

Using a special software component, Tendermint will ask the HSM to sign the consensus message without ever handling the private key itself.

In case of validator compromise, the attacker would not be able to extract your private key and he could only make you double sign as long as he controls your host.

This can be further mitigated by having an encrypted session between Tendermint and the HSM and doing proper secrets management. With such measures in place, it would be harder for a validator to get the HSM to sign arbitrary data and you would have more time to detect and mitigate the attack.

HSM implementations

KMS by Tendermint

KMS (Key Management Service) is a reference implementation of pluggable signing modules in a separate software component, maintained by Tendermint.

KMS is a separate process which handles signing and implements double signing protection (like keeping track of the last signed messages).

This component communicates with the Tendermint node using a encrypted channel to prevent MITM attacks ( man-in-the-middle ).

Signers are implemented as plugins which makes is very extensible and flexible. Examples of implemented signers include the YubiHSM2, Ledger Nano S and the traditional file signer mentioned above.

The advantage of running a separate host (or an SGX enclave) for key management is that in case of a validator host compromise, your KMS host will remain secure and the built-in double signing protection in the KMS will prevent it from responding to double signing requests from the compromised validator host.

It is worth remembering that Tendermint KMS is currently beta quality. It has undergone one security audit with only one low-severity finding. https://github.com/iqlusioninc/tmkms#status