Security

On this page

Validator Security #

Learn about sentry nodes and HSMs to secure a validator {synopsis}

Each validator candidate is encouraged to run its operations independently, as diverse setups increase the resilience of the network. Validator candidates should commence their setup phase now in order to be on time for launch.

Horcrux #

Horcrux is a multi-party-computation (MPC) signing service for Tendermint nodes

Take your validator infrastructure to the next level of security and availability:

  • Composed of a cluster of signer nodes in place of the remote signer, enabling High Availability (HA) for block signing through fault tolerance.

  • Secure your validator private key by splitting it across multiple private signer nodes using threshold Ed25519 signatures

  • Add security and availability without sacrificing block sign performance.

See documentation here to learn how to upgrade your validator infrastructure with Horcrux.

Tendermint KMS #

Tendermint KMS is a signature service with support for Hardware Security Modules (HSMs), such as YubiHSM2 and Ledger Nano . It’s intended to be run alongside ICPlaza Validators, ideally on separate physical hosts, providing defense-in-depth for online validator signing keys, double signing protection, and functioning as a central signing service that can be used when operating multiple validators in several ICPlaza Zones.

Hardware HSM #

It is mission critical that an attacker cannot steal a validator’s key. If this is possible, it puts the entire stake delegated to the compromised validator at risk. Hardware security modules are an important strategy for mitigating this risk.

HSM modules must support ed25519 signatures for ICTech. The YubiHSM 2 supports ed25519 and can be used with this YubiKey library.

::: danger 🚨 IMPORTANT: The YubiHSM can protect a private key but cannot ensure in a secure setting that it won’t sign the same block twice. :::

Sentry Nodes (DDOS Protection) #

Validators are responsible for ensuring that the network can sustain denial of service attacks.

One recommended way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture.

Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator’s node directly to its sentry nodes, and may require new sentry nodes be spun up or activated to mitigate attacks on existing ones.

Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet based attacked cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network.

::: tip Read more about Sentry Nodes on the forum :::

To setup your sentry node architecture you can follow the instructions below:

Validators nodes should edit their config.toml:

# Comma separated list of nodes to keep persistent connections to
# Do not add private peers to this list if you don't want them advertised
persistent_peers =[list of sentry nodes]

# Set true to enable the peer-exchange reactor
pex = false

Sentry Nodes should edit their config.toml:

# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
# Example ID: 3e16af0cead27979e1fc3dac57d03df3c7a77acc@3.87.179.235:26656

private_peer_ids = "node_ids_of_private_peers"

Environment Variables #

By default, uppercase environment variables with the following prefixes will replace lowercase command-line flags:

  • ICTech (for ICTech flags)

  • TM (for Tendermint flags)

  • BC (for democli or basecli flags)

For example, the environment variable ICTech_CHAIN_ID will map to the command line flag --chain-id. Note that while explicit command-line flags will take precedence over environment variables, environment variables will take precedence over any of your configuration files. For this reason, it’s imperative that you lock down your environment such that any critical parameters are defined as flags on the binary or prevent modification of any environment variables.

Tendermint KMS #

Set up a Key Management System for ICTech {synopsis}

Tendermint KMS is a Key Management Service (KMS) that allows separating key management from Tendermint nodes. In addition it provides other advantages such as:

  • Improved security and risk management policies

  • Unified API and support for various HSM (hardware security modules)

  • Double signing protection (software or hardware based)

It is recommended that the KMS service runs in a separate physical hosts.

Install Tendermint KMS onto the node #

You will need the following 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

::: tip For x86_64 architecture only:

Configure RUSTFLAGS environment variable:

export RUSTFLAGS=-Ctarget-feature=+aes,+ssse3

:::

We are ready to install KMS. There are 2 ways to do this: compile from source or install with Rusts cargo-install. We’ll use the first option.

Compile from source code #

The following example adds --features=ledger to enable Ledger support. tmkms can be compiled directly from the git repository source code, using the following commands:

gh repo clone iqlusioninc/tmkms && cd tmkms
[...]
cargo build --release --features=ledger

Alternatively, substitute --features=yubihsm to enable YubiHSM support.

If successful, it will produce the tmkms executable located at: ./target/release/tmkms.

Configuration #

A KMS can be configured using the following HSMs

YubiHSM #

Detailed information on how to setup a KMS with YubiHSM 2 can be found here.

Ledger Tendermint app #

Detailed information on how to setup a KMS with Ledger Tendermint App can be found [here].

Validator Security #

Learn about sentry nodes and HSMs to secure a validator {synopsis}

Each validator candidate is encouraged to run its operations independently, as diverse setups increase the resilience of the network. Validator candidates should commence their setup phase now in order to be on time for launch.

Horcrux #

Horcrux is a multi-party-computation (MPC) signing service for Tendermint nodes

Take your validator infrastructure to the next level of security and availability:

  • Composed of a cluster of signer nodes in place of the remote signer, enabling High Availability (HA) for block signing through fault tolerance.

  • Secure your validator private key by splitting it across multiple private signer nodes using threshold Ed25519 signatures

  • Add security and availability without sacrificing block sign performance.

See documentation here to learn how to upgrade your validator infrastructure with Horcrux.

Tendermint KMS #

Tendermint KMS is a signature service with support for Hardware Security Modules (HSMs), such as YubiHSM2 and Ledger Nano . It’s intended to be run alongside ICTech Validators, ideally on separate physical hosts, providing defense-in-depth for online validator signing keys, double signing protection, and functioning as a central signing service that can be used when operating multiple validators in several ICTech Zones.

Hardware HSM #

It is mission critical that an attacker cannot steal a validator’s key. If this is possible, it puts the entire stake delegated to the compromised validator at risk. Hardware security modules are an important strategy for mitigating this risk.

HSM modules must support ed25519 signatures for ICTech. The YubiHSM 2 supports ed25519 and can be used with this YubiKey library.

::: danger 🚨 IMPORTANT: The YubiHSM can protect a private key but cannot ensure in a secure setting that it won’t sign the same block twice. :::

Sentry Nodes (DDOS Protection) #

Validators are responsible for ensuring that the network can sustain denial of service attacks.

One recommended way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture.

Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator’s node directly to its sentry nodes, and may require new sentry nodes be spun up or activated to mitigate attacks on existing ones.

Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet based attacked cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network.

::: tip Read more about Sentry Nodes on the forum :::

To setup your sentry node architecture you can follow the instructions below:

Validators nodes should edit their config.toml:

# Comma separated list of nodes to keep persistent connections to
# Do not add private peers to this list if you don't want them advertised
persistent_peers =[list of sentry nodes]

# Set true to enable the peer-exchange reactor
pex = false

Sentry Nodes should edit their config.toml:

# Comma separated list of peer IDs to keep private (will not be gossiped to other peers)
# Example ID: 3e16af0cead27979e1fc3dac57d03df3c7a77acc@3.87.179.235:26656

private_peer_ids = "node_ids_of_private_peers"

Environment Variables #

By default, uppercase environment variables with the following prefixes will replace lowercase command-line flags:

  • ICTech (for ICTech flags)

  • TM (for Tendermint flags)

  • BC (for democli or basecli flags)

For example, the environment variable ICTech_CHAIN_ID will map to the command line flag --chain-id. Note that while explicit command-line flags will take precedence over environment variables, environment variables will take precedence over any of your configuration files. For this reason, it’s imperative that you lock down your environment such that any critical parameters are defined as flags on the binary or prevent modification of any environment variables.

Validator Backup #

Learn how to backup your validator. {synopsis}

It is crucial to backup your validator’s private key. It’s the only way to restore your validator in the event of a disaster.

The validator private key is a Tendermint Key: a unique key used to sign consensus votes.

To backup everything you need to restore your validator, note that if you are using the “software sign” (the default signing method of Tendermint), your Tendermint key is located at:

~/.ICPlazad/config/priv_validator_key.json

Then do the following:

  1. Backup the json file mentioned above (or backup the whole config folder).

  2. Backup the self-delegator wallet. See backing up wallets with the ICPlaza Daemon.

To see your validator’s associated public key:

ICPlazad tendermint show-validator

To see your validator’s associated bech32 address:

ICPlazad tendermint show-address

You can also use hardware to store your Tendermint Key much more safely, such as YubiHSM2.

← Validator FAQ

overview →

PreviousValidator FAQNextoverview

Last updated