Key management
🔐 Keyring
Node security
The keyring is used to store and manage the keys used to interact with Validator nodes and other nodes. The keyring allows private keys to be stored securely without being exposed to a potential attacker. The keyring can be interacted with using the cudos-noded
CLI tool.
Several backend implementations can be configured as part of setting up the keyring to store private keys.
The os
backend (default)
This is the backend chosen for the rest of this guide.
os
is the default option as OS credential managers are designed to meet most common needs and provide a streamlined experience without compromising on security.
The os
backend uses operating system-specific defaults to handle credentials and key storage securely. These include password prompts and user sessions according to user defined password policies. Here is a list of the most popular operating systems and their respective passwords manager.
macOS (since Mac OS 8.6): Keychain View details at external site
Windows: Credentials Management API View details at external site
GNU/Linux:
- libsecret View details at external site
- kwallet View details at external site
The file
backend
Recommended for a headless environment.
The file
backend stores the keyring encrypted inside the application configuration directory. A password is requested each time the keyring is accessed.
The first time you add a key to an empty keyring, you are prompted to type the password twice.
The pass
backend
Recommended for a headless environment.
The pass
backend uses the pass utility to manage on-disk encryption of keys' sensitive data and metadata. Keys are stored inside gpg
encrypted files within app-specific directories. pass
is available for the most popular UNIX operating systems as well as GNU/Linux distributions.
The test
backend
The test
backend is a password-less variation of the file backend. Keys are stored unencrypted on disk.
For testing purposes only.
#The memory backend The memory backend stores keys in memory. The keys are immediately deleted after the program has exited.
For testing purposes only.
How to add a new key to the keyring
In this example, we'll add a new key to a test
backend and store it as a variable.
$ cudosnoded keys add testytestkey --keyring-backend test
# Store the generated address as a variable
TESTYTESTKEY_ADDRESS
Third party security options
Validator Operators must consider whether they want to be fully responsible for Key Management or if they want to leverage third-party infrastructure to do so.
Tendermint Key Management System (KMS) (Beta)
Validators can research the Key Management System intended for Cosmos Validators. Check it out.
It provides isolated, optionally HSM-backed signing key management for transaction signing. Designed to be deployed on separate physical hosts. It provides the following:
- High-availability access to validator signing keys
- Double-signing prevention even in the event the validator process is compromised
- Hardware security module storage for validator keys which can survive host compromise
Hardware Security Modules
Solutions for cloud-based infrastructure are still evolving. Check out discussions on Cosmos Hub Forum and in Validator Chat in Discord.
HSM modules must support ed25519
signatures. The YubiHSM2 supports ed25519
.
The following Yubikey library is available
The YubiKey is a hardware authentication device manufactured by Yubico to protect access to computers, networks, and online services. It supports one-time passwords (OTP), public-key cryptography, and authentication. It allows users to securely log into their accounts by emitting one-time passwords or using a FIDO-based public/private key pair generated by the device.