As a validator in the Cosmos ecosystem, as with any other blockchain, one of our main jobs is to secure the network or networks we are operating on. But if we are not properly securing our own servers and private keys, how can we expect to properly to our part to protect the network?
In this post we are going to talk about what TMKMS is and why it is important. Not only that, we are including a full installation guide on how to set up TMKMS for your validator.
What is TMKMS?
The TMKMS, which is short for Tendermint Key Management System, is s library for the Rust programming language, which is what most Cosmos SDK blockchains are built on.
What it does is provides isolated, optionally HSM-backed signing key management for Tendermint applications including validators, oracles, IBC relayers, and other transaction signing applications. It separates the signing process from the validator, allowing to perform the signing process in different hosts. This increases protection against double signing.
When a validator double signs a transaction, it basically equals death for that validator, at least on that chain. But not only that, it will hurt the overall reputation of the validator and may end up killing support for them on any chain they are running.
What is Double Signing?
Double signing happens when a validator submits two signed messages for the same block. This can happen if a node operator or infrastructure provider optimizes their node configuration to prevent downtime by having a highly available backup entity running at the same time as a primary entity. Double signing is looked at as an attack on the network.
Having TMKMS setup on a separate server that holds the private keys for a validator prevents this issue. Having the private keys held on a separate server helps to keep them protected and can route the signing to the signing validator. If something happens to that signing validator, all that needs to be done is point the TMKMS server to the backup node. This should be said to that the backup server needs to be a different machine, and for high security, in a different region all together or country all together.
Setting Up TMKMS
The following information is pulled from the TMKMS Github, so if you want to follow the official documentation from the library devs, you can check it out there. But we felt like it was good to add into this post as well...
First off, you will need 2 servers, one as your validator and the other will be your TMKMS server. We are going to focus only on the TMKMS server for now.
Operating Systems
They do note in the GitHub that the library is presently tested and preferably operates on Linux/x86_64. It should work on the following operating system, but they are at your own risk:
FreeBSD
NetBSD
OpenBSD
macOS
Basically the main UNIX based operating systems...
CPU Architecture
You can run either 32 bit or 64 bit CPU architectures, although 64 bit is always recommended:
x86_64 (recommended)
arm (32-bit ARM)
aarch64 (64-bit ARM)
riscv32 (32-bit RISC-V)
riscv64 (64-bit RISC-V)
Prerequisites
Rust (stable; 1.56+): https://rustup.rs/
C compiler: e.g. gcc, clang
pkg-config
libusb (1.0+). Install instructions for common platforms:
Debian/Ubuntu:
apt install libusb-1.0-0-dev
RedHat/CentOS:
yum install libusb1-devel
macOS (Homebrew):
brew install libusb
NOTE (x86_64 only): Configure RUSTFLAGS environment variable: export RUSTFLAGS=-Ctarget-feature=+aes,+ssse3
Now For The Installation
The TMKMS server should have a firewall with all the ports closed except the SSH port. The recommendation is to use a different SSH port than the default port 22, but we will use it as an example:
sudo ufw allow 22 ssh
sudo ufw enable
It would be best to allow SSH connections just from the authorized machines, so the command would look like this:
sudo ufw allow from to any port 22
Once this is configured, we proceed to install Cargo and TMKMS:
sudo apt update
sudo apt install build-essential git
curl https://sh.rustup.rs -sSf | sh
Compiling From Source Code (via GitHub)
TMKMS can be compiled directly from the git repository source code using the following method.
The following example adds --features=yubihsm to enable YubiHSM 2 support.
$ git clone https://github.com/iqlusioninc/tmkms.git && cd tmkms
Now for Cargo. If we have a local server, the most secure solution is to use Yubikey HSM signing.
$ cargo build --release --features=yubihsm
You can also use a Ledger hardware wallet in which you would use:
--features=ledger
Alternatively, it can be configured to use software signature (Soft-sign) on a cloud server.
--features=softsign
If successful, this will produce a tmkms executable located at ./target/release/tmkms
Installing Cargo
With Rust (1.56+) installed, you can install TMKMS with the following:
cargo install tmkms --features=yubihsm
Or to install a specific version (recommended):
cargo install tmkms --features=yubihsm --version=0.4.0
Alternatively, substitute --features=ledger to enable Ledger support or --features=softsign for cloud servers.
Configuration: TMKMS init
The tmkms init command can be used to generate a directory containing the configuration files needed to run the KMS. Run the following:
$ tmkms init /path/to/kms/home
This will output a tmkms.toml file, a kms-identity.key (used to authenticate the KMS to the validator), and create secrets and state subdirectories.
Please look through tmkms.toml after it's generated, as various sections will require some customization.
The tmkms init command also accepts a -n or --networks argument which can be used to specify certain well-known Tendermint chains to initialize:
$ tmkms init -n cosmoshub,irishub,columbus /path/to/kms/home
Running: TMKMS start
After creating the configuration, start TMKMS with the following command:
$ tmkms start
This will read the configuration from the tmkms.toml file in the current working directory.
To explicitly specify the path to the configuration, use the -c flag:
$ tmkms start -c /path/to/tmkms.toml
Now To Connect To Your Chain
Once you have finished the above steps, you are finished with the primary setup needed to run a validator with TMKMS enabled. You will then need to check the specific chain you are wanting to validate for for specific setups.
Most chains should have setup guides in their documents that will help you get your TMKMS set up for that specific chain.
If you are a developer and want to set up a developer environment as well as testing environments, the GitHub offers further steps for setting that up, but we will not be going into them in this article.
Hope this guide has helped you to better understand what TMKMS is and why it is so important in the Cosmos ecosystem, especially for those of use that are validating the blockchain!
If your validator running TMKMS and properly securing their nodes and protecting the chain against double signing attacks? Here at carbonZERO, we take security seriously and have TMKMS set up on all of our chains we validate for! This not only protects our private keys, but helps ensure our nodes are properly doing their job and protecting theses valuable networks!
We Are carbonZERO
carbonZERO is a full service, eco-conscious validator node operator for the Cosmos ecosystem, providing infrastructure for several blockchain in the Cosmos ecosystem. We run top of the line bare metal servers, utilizing 64GB RAM, 1TB NVMe SSDs, and 8-core / 16-thread CPUs. Our node architecture consists of frontline sentry nodes for ultimate security as well as private key and double signing protection using TMKMS.
Stake your $CMDX, $ROWAN, $HUAHUA, $CRBRUS, and $NOM with carbonZERO using our Restake app! You can also visit the Staking page on Coin Logic and click the chain you want to delegate and it will take you directly to our delegation page!
Follow us on Twitter!
Follow us on LeoFinance on Hive!
Posted Using LeoFinance Beta
The rewards earned on this comment will go directly to the people( @carbonzerozone ) sharing the post on Twitter as long as they are registered with @poshtoken. Sign up at https://hiveposh.com.
Congratulations @carbonzerozone! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s):
Your next target is to reach 20 posts.
Your next target is to reach 900 upvotes.
Your next target is to reach 100 replies.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOP
To support your work, I also upvoted your post!
Support the HiveBuzz project. Vote for our proposal!
Hi, I'm looking for information about the SMB3 networking protocol, what versions it had, what were the differences in them, etc. I need this for a student paper.
Posted Using LeoFinance Beta
As it is clear from the number, there were 3 versions, each version had its own additions, 1.1, 2.2, etc. Microsoft did a great job when they created this network protocol, as it allows you to organize the work with files between users and the server at the best level, even under high load there is always the possibility of quick access to the file in multi-threaded mode. More details about smb3 read here.