SOLVED: YubiHSM2 Minimal Capabilities for Signing
Key 0x0001 has the Validator Consensus key, so tmkms.toml is for now as
auth = { key = 1, password_file = "/path/to/pword" }
keys = [{ chain_ids = ["cosmoshub-2"], key = 1 }]
The file pword contains the YubiHSM master password. I need to have another auth key (such as operator) that can sign with the validator consensus key, so that I can specify this auth key in tmkms.toml and leave only the password for it (not the master password) in the KMS machine.
What are the minimum capabilities required by this 2nd auth key in order to accomplish this?
PS: I generated the validator consensus key in software in a brand new machine, imported it into the HSM, and wiped it from the disk of the machine where it was generated. I keep a copy of this key in an airgapped (very well encrypted) password safe. Since I only have 1 YubiHSM for now, I need to have a copy of the key to be able to switch validation from the main to one of the spare nodes in case of disaster. Am I missing something or is this the only route when you only have 1 YubiHSM?
Hello. Note there is a fully automated setup feature which automatically generates a suggested role configuration with appropriate capabilities per authentication key: github.com tendermint/kms/blob/master/README.yubihsm.md#production-yubihsm-2-setup ``` # YubiHSM 2 + Tendermint KMS The [YubiHSM 2] from Yubico is a relatively low-cost solution for online key storage featuring support for random key generation, encrypted backup and export, and audit logging. This document describes how to configure a YubiHSM 2 for production use with Tendermint KMS. ## Compiling `tmkms` with YubiHSM support Please see the [toplevel README.md] for prerequisites for compiling `tmkms` from source code. You will need: Rust (stable, 1.35+), a C compiler, `pkg-config`, and `libusb` (1.0+) installed. There are two ways to install `tmkms` with YubiHSM 2 support, and in either case, you will need to pass the `--features=yubihsm` parameter to enable YubiHSM 2 support: ### Compiling from source code (via git) ``` This file has been truncated. show original If you would prefer to create a bespoke configuration, you can find the default list of capabilities the…
Excerpt (1196 of 2149 characters). Read the whole post on the forum ↗
All set, thanks again Tony!
I decided to simplify the roles and auth-keys stored and used only 1 signing key, 2 auth keys.
For reference, this is the cmd used for creating the 2nd authkey:
put authkey <session-id> <key-id, 2> tmkms-auth all sign-ecdsa,sign-eddsa,sign-attestation-certificate,get-log-entries sign-ecdsa,sign-eddsa,sign-attestation-certificate,get-log-entries <password>
And here’s another suggested auth key role setup.
My problem is solved, but the one question is left:
Is importing a software generated key the only route when you only have 1 YubiHSM and might need to validate from a machine that does not have access to the HSM? I assume yes because it is only exportable under wrap.
Yes, plaintext keys only go into the YubiHSM, they don’t come back out